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

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2014-11-14 at 14:53 -0200, Alexandre Oliva wrote:
> On Nov 14, 2014, Torvald Riegel <triegel@redhat.com> wrote:
> 
> > AFAICT memset_s is still a sequentially-specified function.
> 
> How can you tell?  It's not like the standard explicitly says so, is it?
> It can't be the as-if rule if intermediate results can be observed in
> ways that are not ruled out by the standard.

If we're talking about C11, which Florian cited, then the by-default
data-race freedom requirement applies, and memset_s doesn't say anything
about atomicity or ordering, so if you would observe intermediate
states, you'd have a race condition.  You wouldn't have a race condition
if you'd have an observer that happens-before the memset_s or have the
memset_s happens-before the observer.  IOW, you're not allowed to look
at the intermediate states.

If we disregard data-race freedom for a second, memset_s is, in
comparison to memset, a little special in that it says that the function
has to be executed strictly according to the rules of the abstract
machine.  That may look like it could be useful for concurrent settings,
but then you still have the issue that observers need to be constrained
as well, execution under racing accesses from multiple threads is still
undefined, and there's no memory ordering (which matters less in related
ctermid case of concurrent memset_s to the same memory locations because
you just store store store).  memset_s doesn't specify any of that, so,
by absence of defined semantics, it's still a sequential function to me.

The way I read the special memset_s requirements is that if the
function's execution is terminated prematurely because of violating the
runtime constraints, that an observer then get an as-if to the abstract
machine.  Not that you can just observe the results without it being
terminated.
Also, C11 states in 3.7.4.1p4: "Unlike memset, any call to
the memset_s function shall be evaluated strictly according to the rules
of the abstract machine as described in (5.1.2.3)."  This indicates that
memset can write intermediate states; otherwise, the standard wouldn't
need to state the deviation from the default for memset_s.

If the standard doesn't define semantics of multi-threaded executions, I
disagree that you can assume some semantics for it; it's undefined, so
like undefined behavior, you can get anything.