This is the mail archive of the
mailing list for the glibc project.
Re: ctermid: return string literal, document MT-Safety pitfall
- From: Florian Weimer <fweimer at redhat dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 17 Nov 2014 08:53:26 +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>
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. Java has this even in the
presence of data races, but I don't think GCC provides this for C11. If
all data races are indeed undefined behavior, the fact that the standard
makes a contrary claim about how the memory model works (see the
previous discussion with Torvald for a quote from the standard) does not
Florian Weimer / Red Hat Product Security