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

Terry Lambert wrote:
> Stefan Farfeleder wrote:
> > On Mon, Nov 24, 2003 at 07:05:02PM +0100, boyd, rounin wrote:
> > > From: "Jacques A. Vidrine" <nectar_at_FreeBSD.org>
> > > > The application is broken.  You must only check errno if you get an
> > > > error indication from the library call.
> > >
> > > errno is only meaningful after a syscall error.
> > 
> > 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.

Wrong, strtol() can set errno in two cases, when the value is outside
the range of representable values or when no conversion could be
performed.  In the former case it will either return LONG_MIN or
LONG_MAX and set errno to ERANGE, in the latter case it will return 0
and set errno to EINVAL.  The return value of -1 has thus no special
meaning and if your strtol() implementation is standard compliant and
you set errno to 0 prior to calling it as you should, errno will always
be 0 after strtol() has returned -1.

The only cases where there is a _potential_ error returned by strtol()
is when it returns 0, LONG_MIN or LONG_MAX.

The behaviour described here is for a strtol() compliant with the IEEE
Std 1003.1-2001 standard.  In strict ISO C, strtol() is not forced to
set errno to EINVAL when no conversions could be performed, it only has
to return 0.  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.

In any case, a return value of -1 does not mean anything for strtol().

Cheers,
Maxime