Re: [PATCH 1/9] interface additions for the C thread implementation

[Alexander Monakov <amonakov@ispras.ru>]

On Sun, 7 Sep 2014, 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.

Ah, I completely misunderstood then.  But then your suggestion is equally
applicable to pthread types, no?  It sounded like you were suggesting to do
that for C11 types only.

Alexander