`errno' (Dan Pop)

[Vijay Kumar R Zanvar]

> In <pa************ *************** *@bar.net> "Mac" <fo*@bar.net> writes:

Is it legal to declare errno after you've included errno.h?

For example:

#include<errno .h>

...

int main (void)
{
extern int errno;

...

}

I see in the standard that errno may be a macro, and I see that defining
errno is illegal, but I don't think the declaration above counts as a
definition since it doesn't reserve storage. On the other hand, if errno
IS a macro, the declaration above could easily be a syntax error after
pre-processing.

Please enlighten me.
Your analysis is correct. You cannot even declare errno, because it can
be (and quite often is) defined as a macro in <errno.h>. The common
reason for this is allowing multithreaded applications to have a per
thread errno, rather than sharing a global errno. This is one of the
few places where the C standard cares about multithreading.

[Today I happened to see that this mail was hiding in the "Drafts" folder
for more than a month!]

I am at loss as how defining `errno' as a macro can be helpful in
multithreading applications. Please enlighten me.

--
Vijay
The common macro definition for errno is along the lines:

#define errno (*__errno())

So, if you need to access errno, include <errno.h> and use whatever
definition/declaration it provides.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Christian Bau]

In article <2i************ @uni-berlin.de>,
"Vijay Kumar R Zanvar" <vi*****@global edgesoft.com> wrote:

I am at loss as how defining `errno' as a macro can be helpful in
multithreading applications. Please enlighten me.

If "errno" were a plain extern variable, then all threads in a
multithreading application would always see the same "errno" variable.
So if thread A calls a function which might change errno, then checks
errno immediately after the function call, then another thread B could
be calling a different function modifying errno just before thread A
reads the value of errno. So thread A might read the wrong value.

In multithreading applications, you usually have a modified standard
library where every thread has its own "errno" variable, and a library
function called by thread X modifies the errno variable belonging to
thread X. Usually errno is a macro defined as a function call returning
the errno variable of the current thread.

[Keith Thompson]

"Vijay Kumar R Zanvar" <vi*****@global edgesoft.com> writes:
[...]

I am at loss as how defining `errno' as a macro can be helpful in
multithreading applications. Please enlighten me.

As Dan wrote:

The common macro definition for errno is along the lines:

#define errno (*__errno())

Assume each thread has its own data area. The hypothetical __errno()
function returns a pointer into the data area of the current thread.
This way, each thread effectively gets its own unique errno variable.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Vijay Kumar R Zanvar]

"Christian Bau" <ch***********@ cbau.freeserve. co.uk> wrote in message
news:ch******** *************** **********@slb-newsm1.svr.pol. co.uk...

In article <2i************ @uni-berlin.de>,
"Vijay Kumar R Zanvar" <vi*****@global edgesoft.com> wrote:

I am at loss as how defining `errno' as a macro can be helpful in
multithreading applications. Please enlighten me.

If "errno" were a plain extern variable, then all threads in a
multithreading application would always see the same "errno" variable.
So if thread A calls a function which might change errno, then checks
errno immediately after the function call, then another thread B could
be calling a different function modifying errno just before thread A
reads the value of errno. So thread A might read the wrong value.

In multithreading applications, you usually have a modified standard
library where every thread has its own "errno" variable, and a library
function called by thread X modifies the errno variable belonging to
thread X. Usually errno is a macro defined as a function call returning
the errno variable of the current thread.

Nicely explained. Thanks.

[Vijay Kumar R Zanvar]

"Keith Thompson" <ks***@mib.or g> wrote in message news:ln******** ****@nuthaus.mi b.org...

"Vijay Kumar R Zanvar" <vi*****@global edgesoft.com> writes:
[...]

I am at loss as how defining `errno' as a macro can be helpful in
multithreading applications. Please enlighten me.
As Dan wrote:

The common macro definition for errno is along the lines:

#define errno (*__errno())

Assume each thread has its own data area. The hypothetical __errno()
function returns a pointer into the data area of the current thread.
This way, each thread effectively gets its own unique errno variable.

This paragraph clears my doubt. Thanks.
--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[those who know me have no need of my name]

in comp.lang.c i read:

In article <2i************ @uni-berlin.de>,
"Vijay Kumar R Zanvar" <vi*****@global edgesoft.com> wrote:

I am at loss as how defining `errno' as a macro can be helpful in
multithreading applications. Please enlighten me.

If "errno" were a plain extern variable, then all threads in a
multithreadi ng application would always see the same "errno" variable.

this is not required or always true (think platform magic). but it's off-
topic so i'll not go into it further.

--
a signature

[Dan Pop]

In <m1************ *@usa.net> those who know me have no need of my name <no************ ****@usa.net> writes:

in comp.lang.c i read:

In article <2i************ @uni-berlin.de>,
"Vijay Kumar R Zanvar" <vi*****@global edgesoft.com> wrote:

I am at loss as how defining `errno' as a macro can be helpful in
multithreading applications. Please enlighten me.

If "errno" were a plain extern variable, then all threads in a ^^^^^^^^^^^^^^^ ^^^^^^^^multithreadin g application would always see the same "errno" variable.

this is not required or always true (think platform magic).

Of course it is required and always true. Once implementation magic gets
involved, errno is no longer "a plain extern variable".

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Richard Tobin]

In article <c9**********@s unnews.cern.ch> , Dan Pop <Da*****@cern.c h> wrote:

I am at loss as how defining `errno' as a macro can be helpful in
multithreading applications. Please enlighten me. If "errno" were a plain extern variable, then all threads in a ^^^^^^^^^^^^^^^ ^^^^^^^^multithreadi ng application would always see the same "errno" variable.

this is not required or always true (think platform magic).

Of course it is required and always true. Once implementation magic gets
involved, errno is no longer "a plain extern variable".

I think by "if errno were a plain extern variable" the poster meant
"if errno's declaration were a plain extern variable declaration", in
contrast to being declared as a macro. At least, that reading is one
that makes his comment comprehensible.

-- Richard

[Xenos]

"Dan Pop" <Da*****@cern.c h> wrote in message
news:c9******** **@sunnews.cern .ch...

Of course it is required and always true. Once implementation magic gets
involved, errno is no longer "a plain extern variable".

I can be. On the environment I work on, it is. Its value is swapped during
a context switch along with the registers.

DrX

[Dan Pop]

In <c9*********@cu i1.lmms.lmco.co m> "Xenos" <do**********@s pamhate.com> writes:

"Dan Pop" <Da*****@cern.c h> wrote in message
news:c9******* ***@sunnews.cer n.ch...

Of course it is required and always true. Once implementation magic gets
involved, errno is no longer "a plain extern variable".

I can be. On the environment I work on, it is. Its value is swapped during
a context switch along with the registers.

This is another way to say that each context has its own errno, which is
perfectly natural and doesn't require any compiler magic. However, a
context switch and a thread switch are not the same thing.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de