Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY

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