[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140828233809.GE12888@brightrain.aerifal.cx>
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.
