Re: ctermid: return string literal, document MT-Safety pitfall

[Florian Weimer <fweimer at redhat dot com>]

On 11/13/2014 10:03 PM, Alexandre Oliva wrote:
> On Nov 11, 2014, Florian Weimer <fweimer@redhat.com> 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 
(7.14.1.1/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:

  <https://bugs.openjdk.java.net/browse/JDK-6948537>

--
Florian Weimer / Red Hat Product Security