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

Jacques A. Vidrine nectar at FreeBSD.org
Tue Nov 25 13:41:16 PST 2003

On Tue, Nov 25, 2003 at 04:46:24PM +0200, Enache Adrian wrote:
> On Mon, Nov 24, 2003 a.d., Jacques A. Vidrine wrote:
> > The application is broken.  You must only check errno if you get an
> > error indication from the library call.
> Sorry, but I don't see your point. I know when to check for errno.
> If you took the little illustrating program for a real life example of
> the use of errno, that's unfortunate :-)
> The problem is that the emulated/wrapped close from libc_r does not
> behave like the real one. libc_r is leaking some of its guts
> (the tricks it's doing with O_NONBLOCK, etc) in the interface.
> This is technically a bug. The fix was trivial.

Hello Enache,

My point was that this is not technically a bug.  According to
IEEE Std 1003.1-2001 aka the Single Unix Specification Version 3
(``SUSv3'') aka POSIX, an application must not examine and interpret
`errno' unless the library gives an error indication.

There are some functions--- strtol and family, sysconf, others---
that have unusual, errno-preserving behavior.  These are described
individually in the appropriate section of the standard.  For these
and only these, you can set errno to 0 and check it immediately after
the function call to see whether an error has occurred.  I believe
that includes all functions described in ISO/IEC 9899:1999 (``C99''),
as well as some described only in SUSv3. `close' is not a part of
C99, nor is it attributed the `unusual', errno-preserving behavior in

(By the way, this exact topic was discuss at some length by the the
Austin Common Standards Revision Group this past summer.)

Jacques Vidrine   NTT/Verio SME      FreeBSD UNIX       Heimdal
nectar at celabo.org jvidrine at verio.net nectar at freebsd.org nectar at kth.se

More information about the freebsd-current mailing list