[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 7 Sep 2014 15:31:36 +0400 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 1/9] interface additions for the C thread
implementation
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
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.
