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: Fri, 14 Nov 2014 13:01:29 +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>
On 11/13/2014 10:03 PM, Alexandre Oliva wrote:
On Nov 11, 2014, Florian Weimer <firstname.lastname@example.org> wrote:
On 11/07/2014 09:35 AM, Alexandre Oliva wrote:
This was based on an interpretation that strcpy (and memcpy, and
compiler-inlined versions thereof) could not write garbage in the
destination before writing the intended values, because this would be a
deviation from the specification, and it could be observed by an
asynchronous signal handler.
Which specification do you mean? glibc or the C standard?
I meant standard C.
I've been staring at the standard for a while. The standard explicitly
refuses to deal with the interaction of signal handlers and threads
(184.108.40.206/7, “Use of this function in a multi-threaded program results
in undefined behavior.”).
However, the standard still required that lock-free atomic objects have
values which are not unspecified. But as far as I can tell, the
standard does not explicitly sequence operations on atomic objects, so
the normal sequencing rules apply, and they fail to specify a value, so
the value is still effectively unspecified, and library functions such
as memcpy and memset can write ghost values, or can be implemented with
one-char-at-a-time loops, and there is no way to observe that.
This (the “not unspecified but not specified either” state) seems to be
a defect in the standard. I very much doubt the intent was invalidate
existing implementations which write ghost values, such as the
Solaris/SPARC memset implementation:
Florian Weimer / Red Hat Product Security