[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140907011926.GY23797@brightrain.aerifal.cx>
Date: Sat, 6 Sep 2014 21:19:26 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 1/9] interface additions for the C thread
implementation
On Mon, Sep 01, 2014 at 12:45:47AM +0200, Jens Gustedt wrote:
> This adds all the constant, type and function interfaces.
>
> 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.
This would only matter if assignment (comparison of aggregates doesn't
even exist in C) were happening between objects of the corresponding
C11 and pthread type in the same TU, which is invalid anyway. Nothing
in the way these types are implemented precludes assignment between
objects of the same type (e.g. mtx_t and mtx_t) or assignment to the
opposite (but compatible) type from a different TU (think of
pthread_mutex_init writing to a mtx_t in the application via
assignment to the dereferenced pthread_mutex_t pointer, which would
have been a possible implementation choice for mtx_init).
BTW there's nothing in the standard to preclude assignment of mtx_t
objects or cnd_t objects that would otherwise be legal, but there's
also no reason to think you should be able to use such a copy with the
threads.h functions. POSIX explicitly spells out the fact that you
can't do this for POSIX sync objects, so if C11 doesn't do the same,
this is probably another defect you should file. Obviously it's
intended that mtx_t objects could hold handles to a system resource
_OR_ actually be the in-memory sync object, so there's no way
assignment could be expected to produce an object that well-defined
behavior.
> - 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.
I didn't understand what this has to do with the choice of
implementation.
> - any calls to standard functions use pointers, and because pointer
> representations for struct types are the same.
The type compatibility rules would also apply to aggregates passed by
value between TUs.
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.
