Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 26 Jul 2014 05:03:54 -0400
From: Rich Felker <>
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


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.