ctermid: return string literal, document MT-Safety pitfall

[Florian Weimer]

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