This is the mail archive of the
mailing list for the glibc project.
Re: ctermid: return string literal, document MT-Safety pitfall
- From: Torvald Riegel <triegel at redhat dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Mon, 17 Nov 2014 10:44:20 +0100
- 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>
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.
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
Also, C11 states in 184.108.40.206p4: "Unlike memset, any call to
the memset_s function shall be evaluated strictly according to the rules
of the abstract machine as described in (220.127.116.11)." 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.