From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5971 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: C threads, v. 6.2 Date: Thu, 28 Aug 2014 19:38:09 -0400 Message-ID: <20140828233809.GE12888@brightrain.aerifal.cx> References: <1409177505.4476.75.camel@eris.loria.fr> <20140827234657.GW12888@brightrain.aerifal.cx> <1409218850.4476.96.camel@eris.loria.fr> <20140828161552.GY12888@brightrain.aerifal.cx> <1409254089.4476.137.camel@eris.loria.fr> <20140828200029.GA12888@brightrain.aerifal.cx> <1409261653.4476.142.camel@eris.loria.fr> <20140828215641.GD12888@brightrain.aerifal.cx> <1409268337.4476.151.camel@eris.loria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1409269110 10160 80.91.229.3 (28 Aug 2014 23:38:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Aug 2014 23:38:30 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5978-gllmg-musl=m.gmane.org@lists.openwall.com Fri Aug 29 01:38:23 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XN9Go-0008Ir-Dm for gllmg-musl@plane.gmane.org; Fri, 29 Aug 2014 01:38:22 +0200 Original-Received: (qmail 5649 invoked by uid 550); 28 Aug 2014 23:38:21 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 5640 invoked from network); 28 Aug 2014 23:38:21 -0000 Content-Disposition: inline In-Reply-To: <1409268337.4476.151.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5971 Archived-At: 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