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.