Very Computer

Thanks for your help.
--
Pierre Decrocq - SLIGOS Payment Services France

Quote:Decrocq) writes:
>Does the 'errno' variable belong to a process or to the unix kernel ?

Quote:>it a good thing for an "in-house" library subroutine to set errno or is
>it not recommended (and why) ?

Quote:>Thanks for your help.

"God is real, unless He was declared integer."

The value of errno is not cleared for a successful system call.  It is
set by any system call that returns -1 indicating an error and then
errno can be checked to see what kind of error.  If the next system
call executes successfully then errno is not updated.  You should be
able to write to it but if a system call fails between your write and
your next read the value will probably change unless you happened to
write the value that errno should be for that system call failure.

A small correction: On modern OSs, errno is a thread level concept(note,
I don't say "variable"). In solaris, for example, errno is not a variable -
it is #define'd to a function call (*(___errno())) .
Of course, it still is a user-level thingie.
:
: >it a good thing for an "in-house" library subroutine to set errno or is
: >it not recommended (and why) ?
:
: If you know what you're doing :^) !.. some subsequent system call,
: hidden inside library functions, may modify errno.
: You can safely use the values defined in <sys/errno.h> like EPERM,
: ENOENT, ... to indicate error by return value.

If there's any chance this system is going to use threads in the future,
you can't do this.

If not, there are still two ways to understand this question ...
When setting errno, do you propose to use existing values defined in
errno.h, or introduce your own values ?

The former is ok, but I'd be hesitant to use the latter, because a couple
of years from now that value may be used for some wholly unrelated purpose
by the OS vendor.

-Sriram

Quote:>It is an extern variable pulled in from libc at link time.

Q1 - what happens to programs that are not linked with libc ? They should
have no errno. So how will system calls notice it ?

R1 - The fact that only system calls set errno seems to indicate that
errno is an attribute of system calls (kind of like in OO words a private
variable that can be queried from outside). So it seems not to be a good
thing to set it from user programs, although implementation makes it
possible (BTW TLI library designers chose to have their own private error
code variable).

--
Pierre Decrocq - SLIGOS Payment Services France

Quote:

>A small correction: On modern OSs, errno is a thread level concept(note,
>I don't say "variable"). In solaris, for example, errno is not a variable -
>it is #define'd to a function call (*(___errno())) .
>Of course, it still is a user-level thingie.

In non-threaded code, it's the good old traditional int, one per process.

Quote:>: If you know what you're doing :^) !.. some subsequent system call,
>: hidden inside library functions, may modify errno.
>: You can safely use the values defined in <sys/errno.h> like EPERM,
>: ENOENT, ... to indicate error by return value.

>If there's any chance this system is going to use threads in the future,
>you can't do this.

     errno = ENOENT;

quite transparently due to the:   #define errno (*(___errno()))
becomes:

     *(___errno()) = ENOENT;

i.e. you are setting the errno appropriate to the current thread.

Of course, you need to build your library with -D_REENTRANT if you
think it might be used in threaded code (and you need to ensure all
the functions are indeed reentrant and Multi-thread safe), or you
need to take the special precautions required to link a non-
multi-threaded library into a multi-threaded app (only calling it
from the original thread).

--

Quote:>: >it a good thing for an "in-house" library subroutine to set errno or is
>: >it not recommended (and why) ?
>:
>: If you know what you're doing :^) !.. some subsequent system call,
>: hidden inside library functions, may modify errno.
>: You can safely use the values defined in <sys/errno.h> like EPERM,
>: ENOENT, ... to indicate error by return value.

>If there's any chance this system is going to use threads in the future,
>you can't do this.

    errno = ERANGE;

are still valid and have the expected results.

Quote:>If not, there are still two ways to understand this question ...
>When setting errno, do you propose to use existing values defined in
>errno.h, or introduce your own values ?

>The former is ok, but I'd be hesitant to use the latter, because a couple
>of years from now that value may be used for some wholly unrelated purpose
>by the OS vendor.

BTW: it is incorrect to regard errno as something specifically
associated with system calls; there are a number of standard library
functions which are *not* system calls (at least, not on any system
I know of) and which set errno. The math library is a good example.

[.sig under construction]

--
Pierre Decrocq - SLIGOS Payment Services France

Quote:>When setting errno, do you propose to use existing values defined in
>errno.h, or introduce your own values ?

"#include "/dev/tty" /* Ultimate program -- WiLL do whatever you want */"

Bet you most programs just quietly break down and die... unless
the signal handler remembers to save & restore errno.

So it's not the libraries responsibility to handle this case...

[.sig under construction]