This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On 11/13/2014 10:03 PM, Alexandre Oliva wrote:
On Nov 11, 2014, Florian Weimer <> 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 (, “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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]