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

[Rich Felker <dalias@libc.org>]

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. 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.

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.

Rich