[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1410081238.4856.137.camel@eris.loria.fr>
Date: Sun, 07 Sep 2014 11:13:58 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 1/9] interface additions for the C thread
implementation
Hello,
Am Samstag, den 06.09.2014, 20:21 -0400 schrieb Rich Felker:
> On Mon, Sep 01, 2014 at 12:45:47AM +0200, Jens Gustedt wrote:
> > This adds all the constant, type and function interfaces.
>
> Including some comments here as I work on committing it. Please don't
> take them as critical; just explaining choices made during commit and
> noting where things are different in the version to be committed.
no problem
parts of the inconsistencies you detected come form me refactoring the
patches into more readable chunks than was the development order
> > It makes pthread_mutex_t, mtx_t, pthread_cond_t and cnd_t different
> > types.
> >
> > This only works because
> >
> > - under hood the corresponding pairs of types use exactly the same
> > definition for the type
> >
> > - the types are a struct types without tag name
> >
> > - no comparison or assignment is allowed for any of these types. For
> > the POSIX types this interdiction is written in the standard. For the
> > C thread types, this is an extension that this implementation
> > imposes, but which might be integrated in a later version of the C
> > standard.
> >
> > - initialization is default initialization of an array of int. For the
> > POSIX types, initialization expressions are provided. For C thread
> > types the only initialization foreseen by the standard are the init
> > functions.
> >
> > - any calls to standard functions use pointers, and because pointer
> > representations for struct types are the same.
> >
> > For the C++ API/ABI, these also are different types, now, with type names
> > (that are used for name mangling, e.g) as listed above.
> >
> > Somebody better versed in C++ could perhaps contribute code that
> > overloads the comparison and assignment operators such that a compilation
> > that tries to compare or copy these types fails.
>
> I'm not sure what you meant by this last paragraph.
AFAIR in C++ there are ways to inhibit usage of copy assignment by
declaring some "operator=" function that is never defined. But my C++
has really become rusty.
> > +int cnd_timedwait(cnd_t *restrict, mtx_t *restrict, const struct timespec *restrict);
> > +int cnd_wait(cnd_t *, mtx_t *);
>
> The lack of restrict on cnd_wait is really odd, but I checked and it's
> like that in the standard too... File this as another bug for C11...
> :-)
huh, yea, I didn't even notice, just copied the prototypes from the
standard at the start.
(So implicitly they (willingly or not) assume that cnd_t and mtx can't
alias against each other but with timespec they can :)
On my list, now.
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.
