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

[Florian Weimer <fweimer at redhat dot com>]

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.  Java has this even in the 
presence of data races, but I don't think GCC provides this for C11.  If 
all data races are indeed undefined behavior, the fact that the standard 
makes a contrary claim about how the memory model works (see the 
previous discussion with Torvald for a quote from the standard) does not 
matter.)
--
Florian Weimer / Red Hat Product Security