[PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
Terry Lambert
tlambert2 at mindspring.com
Wed Nov 26 04:44:31 PST 2003
Maxime Henrion wrote:
> Terry Lambert wrote:
> > > Wrong, counter-example: strtol().
> >
> > Wrong; the standard specifies that the errno shall only be
> > checked when the return value is -1. The exception in the
> > strtol() case is only for presetting errno to 0 before you
> > make the call, and making a check only following a -1 return.
[ ... ]
> The only cases where there is a _potential_ error returned by strtol()
> is when it returns 0, LONG_MIN or LONG_MAX.
So check it only in those cases.
I don't see the problem with errno being set willy-nilly in a
library to multiple different values in implementing some standards
defined behaviour, so long as it's indicated correctly.
> Moreover, the implementation may set errno to something
> even when the conversion was successful. So, in strict ISO C, errno is
> meaningful only if strtol() returns LONG_MIN or LONG_MAX.
You should write your code to expect that a 0 return is not
an error indicator, then.
You know, real hardware would SIGFPE...
> In any case, a return value of -1 does not mean anything for strtol().
Which is irrelevent to the discussion about whether or not a
library is allowed to futz errno to non-0 any time it wants.
We all know that the *only* reason this issue arose is that somone
was writing bogus error checking code that did something like:
errno = 0;
(void)some_library_function_returning_neg_one_on_error();
if (errno != 0) {
printf( "I should have checked my return value, but\n");
printf( "standards documents and man pages confuse me.\n");
}
-- Terry
More information about the freebsd-current
mailing list