This is the mail archive of the
mailing list for the glibc project.
Re: ctermid: return string literal, document MT-Safety pitfall
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Tue, 18 Nov 2014 20:23:17 -0200
- Subject: Re: ctermid: return string literal, document MT-Safety pitfall
- Authentication-results: sourceware.org; auth=none
- References: <ortx2b8l2k dot fsf at free dot home> <54620F80 dot 3030001 at redhat dot com> <ortx22ak52 dot fsf at free dot home> <5465EF19 dot 5040802 at redhat dot com> <1415971681 dot 4535 dot 326 dot camel at triegel dot csb> <54660803 dot 1050809 at redhat dot com> <1415973961 dot 4535 dot 331 dot camel at triegel dot csb> <or4mu1iv0p dot fsf at free dot home> <1416217460 dot 4535 dot 361 dot camel at triegel dot csb>
On Nov 17, 2014, Torvald Riegel <firstname.lastname@example.org> wrote:
> On Fri, 2014-11-14 at 14:53 -0200, Alexandre Oliva wrote:
>> On Nov 14, 2014, Torvald Riegel <email@example.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