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/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 matter.)
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]