Re: ctermid: return string literal, document MT-Safety pitfall

[Torvald Riegel <triegel at redhat dot com>]

On Mon, 2014-11-17 at 08:53 +0100, Florian Weimer wrote:
> On 11/15/2014 12:58 AM, Alexandre Oliva wrote:
> > The standard could specify, for example, that it is unspecified, within
> > an interrupting signal handler, whether observed values would be those
> > originally held in the atomic storage, or those that should be put in
> > there by the copy, without permitting any other values.  That would be
> > in line with my understanding, and I'll dare now put forth the idea that
> > the apparent contradiction you point out might be an indication that
> > this was the intent.
> 
> It would mean that memset and memcpy would align the passed-in pointer 
> to the largest possible atomic object size and update the target using 
> atomic instructions of at least this size.  (This might also apply to 
> the string functions.)  Head and tail may not be a multiple of the word 
> size, so we'd need a compare-and-swap loop to cover this case, with 
> quite a bit of performance overhead.
> 
> Personally, I find it rather attractive to leave this unspecified.
> 
> (Note that C11 is a bit ambiguous whether there is a âno values out of 
> thin airâ requirement in the memory model.

I've heard nobody in the C++ committee say that they want to allow
out-of-thin-air values -- and the C and C++ models are supposed to be
equivalent.
For C++, there is such a requirement, even though in a non-normative
note -- but just because it's hard to specify precisely.

See this paper for details (e.g., Section 4):
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4136.pdf

But, I don't think this specificaton problem is critical for us; the
paper also states: "This is a high-level-language specification problem:
there is no suggestion that thin-air executions occur in practice with
current compilers and hardware; the problem is rather how to exclude
them without preventing desired compiler optimisations."

> Java has this even in the 
> presence of data races,

... and that makes it hard for them.

> but I don't think GCC provides this for C11.

Agreed.  Data races are undefined behavior as stated by C11.  That
doesn't mean that everything that would be a data race under C11 also
leads to a program crash, for example, when compiled by GCC.