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

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2014-11-14 at 14:47 +0100, Florian Weimer wrote:
> On 11/14/2014 02:28 PM, Torvald Riegel wrote:
> > 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.

AFAICT memset_s is still a sequentially-specified function.  Even though
it states that the memory will be modified strictly according to the
rules of the abstract machine, it doesn't state that the stores don't
contribute to data races -- thus, data-race freedom would still be
required.  And it doesn't make the stores atomic.  Also, for a
concurrent observer to actually see the stores in the way they were
issues by the memset_s, it would have to synchronize with the stores;
this would require a statement how that needs to happen.

It could be used to have a "volatile" memset I guess.