[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1406373321.6438.104.camel@eris.loria.fr>
Date: Sat, 26 Jul 2014 13:15:21 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: C11 threads
Am Samstag, den 26.07.2014, 05:03 -0400 schrieb Rich Felker:
> 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 just makes it easier for implementations to chose a consistent set
of values.
> > 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?
probably :)
> 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...
POSIX seems to be a little less restrictive than C, here. It uses the
term "symbolic constant" where C always uses the term "macro"
consistenly all over the place, with threads.h and atomic.h the only
exceptions in using enumerations. And C has the explicit requirement
that all macros that are defined by the standard to resolve to an
"integer constant expression" be such that they can be used in
preprocessor directives.
> 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.
Exactly, so they got it really bad by having added two optional parts
that don't agree on that handling, and that don't even aggree with
themselves. (thrd_sleep has yet another convention, -1 for interrupt
and other negative value for unspecified "failure", and timespec_get
gratuously uses the time base as a return value on success)
What a mess. I'll try to come up with a solution that is the least
intrusive.
Jens
--
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
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.
