bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new module 'errno'


From: Bruno Haible
Subject: Re: new module 'errno'
Date: Tue, 16 Sep 2008 00:26:04 +0200
User-agent: KMail/1.5.4

Hi Eric,

> POSIX 200x adds ENOTRECOVERABLE and EOWNERDEAD (in the
> context of newly mandated robust mutexes), which very few implementations
> are likely to provide yet.

I would not find it wise to add these to our errno.h replacement now, because

  - Generally, I prefer to wait for a standard to be reviewed and released
    before I try to implement it.

  - Most people who refer to POSIX likely look at the web pages
      http://www.opengroup.org/susv3xbd/errno.h.html
    or the manual pages with a 'p' suffix.

  - It would cause 'strerror' to be overridden on nearly all platforms -
    but how many programs already use and assume ENOTRECOVERABLE or
    EOWNERDEAD? None.

> Also, you failed to test for ENODATA (61 on Linux), ENOSR (60), ENOSTR
> (63), and ETIME (62) ...

They are marked as XSR, i.e. they depend on an ancient extension that is only
implemented by Solaris, not by Linux (AFAIK). This is not part of an API that
a portable program is likely to exercise.

> Any reason tests/test-errno.c states this?
> 
> /* Don't verify that these errno values are all different, except for possibly
>    EWOULDBLOCK == EAGAIN.  Even Linux/x86 does not pass this check: it has
>    ENOTSUP == EOPNOTSUPP.  */
> 
> That statement is true for POSIX 2001.  But POSIX 200x added recognition
> of the ENOTSUP/EOPNOTSUPP pairing, such that Linux will be compliant to
> the next version of POSIX without changing errno.h.

The current version is http://www.opengroup.org/susv3xbd/errno.h.html,
and Linux/x86 is not compliant to it.

> I would really like
> to see a test for uniqueness of all of the other errno values.

You are free to add it; but I predict a couple of problems. What will you
do if you, say, find out that on AIX, ENOTEMPTY and EEXIST have the same
value? What is the point of verifying an assertion if the gnulib replacement
cannot fix it?

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]