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: Florian Weimer <fweimer at redhat dot com>
- Cc: Alexandre Oliva <aoliva at redhat dot com>, libc-alpha at sourceware dot org
- Date: Mon, 17 Nov 2014 11:21:33 +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> <or8ujdivcu dot fsf at free dot home> <54667764 dot 3060605 at redhat dot com> <oroas9gwqt dot fsf at free dot home> <5469A976 dot 4070602 at redhat dot com>
On Mon, 2014-11-17 at 08:53 +0100, Florian Weimer wrote:
> On 11/15/2014 12:58 AM, Alexandre Oliva wrote:
> > The standard could specify, for example, that it is unspecified, within
> > an interrupting signal handler, whether observed values would be those
> > originally held in the atomic storage, or those that should be put in
> > there by the copy, without permitting any other values. That would be
> > in line with my understanding, and I'll dare now put forth the idea that
> > the apparent contradiction you point out might be an indication that
> > this was the intent.
> It would mean that memset and memcpy would align the passed-in pointer
> to the largest possible atomic object size and update the target using
> atomic instructions of at least this size. (This might also apply to
> the string functions.) Head and tail may not be a multiple of the word
> size, so we'd need a compare-and-swap loop to cover this case, with
> quite a bit of performance overhead.
> Personally, I find it rather attractive to leave this unspecified.
> (Note that C11 is a bit ambiguous whether there is a âno values out of
> thin airâ requirement in the memory model.
I've heard nobody in the C++ committee say that they want to allow
out-of-thin-air values -- and the C and C++ models are supposed to be
For C++, there is such a requirement, even though in a non-normative
note -- but just because it's hard to specify precisely.
See this paper for details (e.g., Section 4):
But, I don't think this specificaton problem is critical for us; the
paper also states: "This is a high-level-language specification problem:
there is no suggestion that thin-air executions occur in practice with
current compilers and hardware; the problem is rather how to exclude
them without preventing desired compiler optimisations."
> Java has this even in the
> presence of data races,
... and that makes it hard for them.
> but I don't think GCC provides this for C11.
Agreed. Data races are undefined behavior as stated by C11. That
doesn't mean that everything that would be a data race under C11 also
leads to a program crash, for example, when compiled by GCC.