[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140726090354.GK4038@brightrain.aerifal.cx>
Date: Sat, 26 Jul 2014 05:03:54 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: C11 threads
On Sat, Jul 26, 2014 at 10:32:55AM +0200, Jens Gustedt wrote:
> Anybody with reason and with knowledge of POSIX and C (which are
> standards from the same organization, ISO) would just have specified
> error codes in line with pthreads. There are not many places in the
> standard that uses enumeration constants for a similar purpose, and it
> has not much of an advantage. There is the general requirement of the
> standard that all constant integer expressions that it defines must be
> testable by the preprocessor.
I agree that they're ugly and contrary to style used elsewhere in the
standard, but I don't see how cross-polluting this mess with errno.h
makes it any less offensive.
> > It's
> > possible that they might match errno values, but that's certainly an
> > implementation detail, not something that applications could
> > reasonably depend on, and therefore I think it makes no sense to
> > require or allow threads.h to expose errno.h.
>
> As you can see I strongly disagree here. We shouldn't introduce values
> that semantically serve as error return values of library functions
> and that are not regulated by errno.h and that aren't fixed in
> compilation phase 3.
Is this just ideological? POSIX has plenty of such values, such as the
GAI_*, REG_*, FNM_*, WRDE_*, etc. result codes. Maybe there are not
many (any?) in plain C, but C11 added them and I don't think there's
any use in trying to change it now...
Also C has no precedent for _returning_ error codes (excluding of
course Annex K); the errno.h constants are only used with the errno
object.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
