[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1410101101.4856.158.camel@eris.loria.fr>
Date: Sun, 07 Sep 2014 16:45:01 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 1/9] interface additions for the C thread
implementation
Am Sonntag, den 07.09.2014, 07:32 -0400 schrieb Rich Felker:
> On Sun, Sep 07, 2014 at 01:16:43PM +0200, Jens Gustedt wrote:
> > Am Sonntag, den 07.09.2014, 14:05 +0400 schrieb Alexander Monakov:
> > > On Sun, 7 Sep 2014, Jens Gustedt wrote:
> > > > > > For the C++ API/ABI, these also are different types, now, with type names
> > > > > > (that are used for name mangling, e.g) as listed above.
> > > > > >
> > > > > > Somebody better versed in C++ could perhaps contribute code that
> > > > > > overloads the comparison and assignment operators such that a compilation
> > > > > > that tries to compare or copy these types fails.
> > > > >
> > > > > I'm not sure what you meant by this last paragraph.
> > > >
> > > > AFAIR in C++ there are ways to inhibit usage of copy assignment by
> > > > declaring some "operator=" function that is never defined. But my C++
> > > > has really become rusty.
> > >
> > > There's no need to do that since those are unrelated structs, and therefore no
> > > operator== and operator= are available in the first place. You also can't do
> > > that in C (but in C++ you get an error rather than a warning when trying
> > > to assign pointers).
> >
> > This is not about assignment between different types and also not for
> > pointers but for the struct themselves.
> >
> > With the current C threads version the following is a priori allowed,
> > but shouldn't:
> >
> > mtx_t a, b;
> > mtx_init(&a, mtx_plain);
> > b = a;
> >
> > This "works" in C and in C++.
> >
> > The corresponding code in pthreads would be UB.
>
> I'm not clear on whether the assignment is well-defined in pthreads,
> but actually attempting to use the mutex (by passing it to any of the
> pthread_mutex_* functions) would be UB. The same should be true for
> C11 threads; if not, it's a defect.
It is.
> Assignment cannot have predictable
> behavior because:
>
> 1. It could copy a reference (that would later be double-freed if you
> destroyed both after the copy) in which case both copies would be a
> reference to the same underlying mutex.
>
> 2. It could contain pointers to its own storage, in which case the
> copy would be invalid.
>
> 3. It could be completely represented by its internal state, in which
> case you'd have two potentially working mutexes.
>
> 4. It could be a reference to some system-level object linked purely
> to the address of the mtx_t object, in which case the copy would be
> unusable and might even cause system state corruption if used.
>
> Etc.
sure, we all (should) know that, but the average user wouldn't
> I don't think the committee intended to forbid any of the above types
> of implementation; on the contrary it seems they went out of their way
> to support crazy types of implementations, e.g. by omitting
> initializers.
No, unfortunately for the later, the lack of a definition for default
initialization and initializers seems to be intentional. There are
people on the committee who defend the interdiction of statically
initialized mutexes, seemingly because some oldish windows thread
implementation didn't have it.
Jens
--
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
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.
