Date: Fri, 19 Jun 1998 18:51:20 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: fenner@parc.xerox.com (Bill Fenner) Cc: tlambert@primenet.com, peter@netplex.com.au, current@FreeBSD.ORG Subject: Re: Bogus errno twiddling by lstat... Message-ID: <199806191851.LAA12551@usr06.primenet.com> In-Reply-To: <98Jun19.095515pdt.177515@crevenia.parc.xerox.com> from "Bill Fenner" at Jun 19, 98 09:55:00 am
index | next in thread | previous in thread | raw e-mail
> >> 1: This is a classic programming error.. You're not really supposed to be
> >> looking at the value of errno except right after a -1 return from
> >> something.
> >
> >I know I'm not supposed to be. However, it's not supposed to be diddling
> >the errno.
>
> The ANSI C standard says that unless stated otherwise in the standard
> (e.g. the math functions), library functions may change errno even if
> there is no error.
On the other hand, they may leave it alone.
Look, what I was surprised at was the multiple attempts to open
malloc.conf after the first failure in crt0's use of ld.so.
I became concerned, in that it is *perfectly* valid to implement a
POSIX OS using library routines that operate on non-POSIX system
services.
In such a situation, I would not expected these pseduo-system calls
to modify errno, just as I do not expect real system calls to
modify errno.
This alarm comes from somewhere that I can't at present identify: A
system call in SCO Xenix whose failure detection requires the setting
of errno to zero and on a return from the call (whose return value
does not have a namespace incursion like "-1" or "NULL" that can
be relied upon as an error indicator), comparing errno to zero to
see if it was successful (if I recall correctly, the failure case
returned EWOULDBLOCK).
I admit that this is terribly bogus, but it's the ABI, so live with it.
A more prosaic example might be atoi(3), which casts the result
of a strtol(3) to an int. On a machine where an int is 32 bits
and a long is 64 bits, it would be impossible to compare the
return value for the value LONG_MAX, which can't be represented
in 32 bits.
The method you would (presumably) use is:
errno = 0;
i = atoi( buf);
if( errno == ERANGE)
...
So the question becomes: "At what point can I expect a library routine
to behave like a system call"?
I *thought* that there were some ISO/POSIX requirements that errno
not be touched in non-error cases, and that "internally handled"
errors would restore the value to whatever it was before the occurance
of the internal error, thus fully encapsulating the error.
Consider:
errno = 0;
printf( "testing for FreeBSD without malloc.conf....\n");
if( errno == ENOFILE) {
printf( "Sorry, your system is misconfigured!\n");
exit( 1);
}
This is especially an issue for POSIX threads implemented as a user
space call conversion scheduler; they are, in fact, library routines
which wrap system calls.
POSIX threads go to great lengths to do what I would call "the right
thing".
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806191851.LAA12551>