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

[Alexandre Oliva <aoliva at redhat dot com>]

On Nov 17, 2014, Torvald Riegel <triegel@redhat.com> wrote:

> 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.

I'm not asking specifically about memset or strcpy, I'm asking how do
you tell in general.  You've long ago, and again recently, claimed that
such functions as qsort and bsearch have sequential specifications, even
though they have callbacks that must necessarily observe and compute
based on intermediate states.  I'm just trying to figure out what the
heck you mean by âsequential functionâ, and by âsequential
specificationâ.  I had understood the latter had to do with
specifications limited to pre- and post-conditions, but the standards
we've been talking about do not limit function specifications to that.
So, something is clearly amiss.

As for observing intermediate results, we seem to have ruled out as
undefined accesses from other threads, and from interrupting signal
handlers.  This covers almost all possibilities, but how about
cancelling the thread that's running memcpy or strcpy, if it has
asynchronous cancellation enabled?  If you do that, and then
pthread_join completes, you have set a clear happens-before
relationship.  Sure enough, POSIX doesn't require such functions as
memcpy or strcpy to be AC-Safe, but our manual claims our current
implementations are.  Does this mean it is safe to access the variables
that were partially modified by the interrupted memcpy/strcpy/whatever,
and that this provides means to safely inspect intermediate states?  Or
does it mean our manual should not claim these functions to be AC-Safe,
just so that we can claim a program that attempts to inspect
intermediate states of strcpy is undefined behavior?  Or could we resort
to any other argument to make it undefined?

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer