[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1406964692.8274.161.camel@eris.loria.fr>
Date: Sat, 02 Aug 2014 09:31:32 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: C11 error codes
Hello,
starting a new thread (!). I want to single this out, and to
later have good arguments for the discussion with the committee.
Am Freitag, den 01.08.2014, 18:57 -0400 schrieb Rich Felker:
> On Sat, Aug 02, 2014 at 12:21:12AM +0200, Jens Gustedt wrote:
> > Well, the problem is that these constants are not "constants" but come
> > from errno.h. This has two disadvantages:
> >
> > - currently this pollutes the name space of the C thread
> > implementation with the E-names
> >
> > - these constants are arch dependent, we would need another mechanism
> > to get them visible
> >
> > My preferred solution to this is to make a TR to the thread
> > specification, by forcing the obvious choices
>
> I'm not a fan of this solution, and I'd prefer the constants be
> completely independent, especially since they're not semantically
> identical to the POSIX ones. I don't see how C could mandate that they
> be equal to the POSIX ones when it doesn't even define the POSIX ones
> in errno.h. And from a practical standpoint, the fact that the errno
> values vary by arch makes them awkward to use.
I would like to see point by point how the semantics would be
different for each constant. There are not too many constants and if
there is a divergence in semantics, I think it is more likely that
this is due to the underspecification of the whole C thread
business. See below, please.
> Of course the most important thing in choosing these values is to
> avoid an ABI divergence with glibc. And unfortunately I haven't gotten
> any response from their side on how they want to define them.
>
> > and by allowing
> > threads.h to include errno.h. (The optional Annex K sets a precedent
> > by having errno codes as return value for functions.)
>
> There's no precedent for any other header including errno.h
> implicitly, and I'm against adding any such requirement or even
> allowance.
Ok, you are right this would go too far. What is custom though in
POSIX is to *use* the E constants as error returns everywhere. The
current practice is: any user of libc functions who wants to check
error returns (and basically everybody should) has to include errno.h
to get hands on the constant. By that POSIX ensures that everybody has
to include errno.h knowingly to their TU.
> There's a lot more value in keeping the headers independent
> and requiring explicit inclusion of headers you want to use.
right
> > > > +/* Roughly __syscall already returns the right thing: 0 if all went
> > > > + well or a negative error indication, otherwise. Unfortunately the C
> > > > + standard foresees the special case of an interrupted call and fixes
> > > > + that error return to -1 (instead of introducing EINTR). */
> > > > +int thrd_sleep(const struct timespec *req, struct timespec *rem)
> > > > +{
> > > > + int ret = __syscall(SYS_nanosleep, req, rem);
> > > > + // compile time comparison, constant propagated
> > > > + if (EINTR != 1) {
> > > > + switch (ret) {
> > > > + case -EINTR: return -1;
> > > > + case -1: return -EINTR;
> > > > + }
> > > > + }
> > > > + // potentially a tail call
> > > > + return ret;
> > > > +}
> > >
> > > "The thrd_sleep function returns zero if the requested
> > > time has elapsed, -1 if it has been interrupted by a
> > > signal, or a negative value if it fails."
> > >
> > > this is confusing
> >
> > you mean the C standards text is confusing? yes, definitively
> >
> > if you mean the code is confusing, then I should explain it better :)
> >
> > The idea is that if SYS_nanosleep returns -EINTR, thrd_sleep in turn
> > must return -1. If EINTR is in fact 1 on the arch we just can return
> > the value (and 0 if everthing is ok and some undefined value in other
> > UB cases.)
> >
> > If EINTR isn't 1, we have to be careful not to return -1 for some
> > other error code of SYS_nanosleep, whatever happens to be error number
> > 1. So the second case captures such an accidental -1 and sends -EINTR
> > (which we know not to be -1.).
>
> This is kind of clever, but it might just be nicer to hard-code values
> like -1 and -2 rather than swapping -1/-EINTR so that the result looks
> like an errno value but really isn't one...
(right I try to avoid such hackery)
This is another example where C11 gratiously gives up easy integration
with POSIX (which is a standard that is issued by the same
institution, ISO).
To make a list of the error constants for specific error situations
that are introduced by C11:
thrd_timeout
thrd_busy
thre_nomem
-1
(I hope I don't overlook anything)
I think these resemble a lot POSIX'
ETIMEOUT
EBUSY
ENOMEM
EINTR
and if there is a semantic difference with any of them, we should
discuss that. If there is a problem, my first suspicion would be that
C11 didn't do its homework and got things wrong. (For -1 as return of
thrd_sleep this is obvious.)
To my opinion, C11 should have introduced these four new values to the
section about errno.h.
Now let us come to the two remaining values, thrd_success and
thrd_error.
For thrd_success, I think that all our discussions clearly show that
it should just be fixed to 0. There is no point in having it
differently. This puts it in line with POSIX and Annex K. This should
not be problematic.
thrd_error is more difficult. In the best of all worlds this would not
have been defined as it is but in places where it is returned by a
function the formulation should have been something like:
... returns thrd_success in case of success or any positive error
value in case of failure. The failure value should be a value
defined in errno.h or an implementation defined macro value as
specified in Section 7.5
(and then eventually according to the specific function precise
description of the errors, such as when nomem is returned, e.g.)
Now we don't have that, and it is a bit late to bury thrd_error
completely, but I will think of a way and formulation to get this
towards such a usage.
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.
