Date: Thu, 28 Aug 2014 19:38:09 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: C threads, v. 6.2 On Fri, Aug 29, 2014 at 01:25:37AM +0200, Jens Gustedt wrote: > Am Donnerstag, den 28.08.2014, 17:56 -0400 schrieb Rich Felker: > > On Thu, Aug 28, 2014 at 11:34:13PM +0200, Jens Gustedt wrote: > > > Am Donnerstag, den 28.08.2014, 16:00 -0400 schrieb Rich Felker: > > > > On Thu, Aug 28, 2014 at 09:28:09PM +0200, Jens Gustedt wrote: > > > > > at least it doesn't matter for the standard functions (they are `extern > > > > > "C"`) but only for user functions with C++ interfaces. > > > > > > > > Right, but it matters for all C++ code containing C++ functions that > > > > use pthread_mutex_t* as an argument. And apparently there's a lot of > > > > such code. > > > > > > > > > Well, ok, so if you could come up with some better idea in the future, > > > > > let me know. > > > > > > > > I'm not even sure it's an issue. I've seen it argued that aliasing > > > > rules don't even apply here because, when you access something like > > > > m->_m_lock, that's not an "access" to the structure object/type but to > > > > the individual member. If that's true, then as long as the structs > > > > have identical layout, it should be valid to access the members via > > > > either. > > > > > > Yes, there is a special rule for struct types in different TU, that > > > they are compatible when their internal structure is the same > > > (including alignment) and if their *tag* name is the same. > > > > > > > Also, what is the relationship between two identical struct or union > > > > types without tags (i.e. the first member of pthread_mutex_t and the > > > > first member of mtx_t, both of which are unions with no tag)? > > > > > > For structs with no tags the situation is more subtle. If you are in > > > the same TU and declare them in different places they are *not* > > > compatible, basically they are two different struct. On the other hand > > > two such struct in different TU are compatible, if they comply to the > > > above rule of structural equivalence. > > > > Do you have a conclusion from this as to whether what we're doing is > > okay? FWIW the mutex and the code manipulating its internals are > > always in different TUs. > > Yes, what we were doing before and after is ok for C, anyhow. All code Perhaps I should clarify: what I mean by "what we're doing" is defining pthread_mutex_t and mtx_t as separate structs with identical contents (a single union with no tag). Your latest version with __pthread_mutex_t is not a possibility because it changes the C++ ABI. In principle we could do something like with the definition of pthread_t where it changes depending on whether the header is being used in a C or C++ program, but that's quite ugly and not something I'd much like to do... Is your conclusion still that it's okay? I think so but I just want to confirm. > sees exactly the same definitions in the platform specific (generated) > alltypes.h header. All renaming is done through typedef, so there is > no problem at all, this is always the same type, visible through > different names. > > And it even would be ok if one TU would only see it as > __pthread_mutex_t and the other TU as pthread_mutex_t, say. As long as > these are typedef to structures with no tags and exactly the same > layout. > > The problem only occurs for C++, since they seem to have a concept of > "original name" of a type or so. Unless there is a real _practical_ incompatibility, I'm fine with ignoring C++ technicalities where the underlying implementation is already valid C. 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.