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

[Florian Weimer <fweimer at redhat dot com>]

On 11/14/2014 02:28 PM, Torvald Riegel wrote:
> > However, the standard still required that lock-free atomic objects have
> > values which are not unspecified.  But as far as I can tell, the
> > standard does not explicitly sequence operations on atomic objects,
>
> What do you mean by "to sequence"?  The sequenced-before relation can
> include atomic operations, and atomic operations will be part of
> happens-before.

Unlike volatile accesses, access to atomic objects do not contribute to 
the sequenced-before relation directly, only their corresponding full 
expressions do.

> Wanting anything else would require specifying the
> actual implementation, which the standard doesn't do; it might be easy
> to assume that many implementations of a very simple function like
> memset would behave in a certain way -- but this already breaks down
> with more complex functions such as qsort (which intermediate states are
> actually allowed? can it use the to-be-sorted array as scratch space?).
> Also, making assumptions about intermediate states kills the as-if rule,
> hampering compiler optimizations.

It tries to do that for memset_s, but I doubt it succeeds at this (we 
touch this issue briefly before).  I still think the language in the 
standard allows the compiler to elide dead memset_s calls, despite the 
intent.

--
Florian Weimer / Red Hat Product Security