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

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 21 Nov 2014, Alexandre Oliva wrote:

> > So, I agree that these *specific* memory locations are intermediate
> > states, but the comparison functions are not guaranteed to be able to
> > look at other elements of the arrays and find sensible information in
> > those.
> 
> The important question here IMHO is whether looking at them is invokes
> undefined behavior, or just yields unspecified values, possibly narrowed
> to a subset of all values that might be held by the types of the objects
> in those locations, if there can even be valid assumptions about the
> types of those memory locations.

If a location is modified by a function, and the semantics of that 
function do not specify it to be modified as an atomic operation with a 
particular memory order, I think asynchronous accesses result in undefined 
behavior.  At least, they behave like accessing uninitialized automatic 
storage or struct padding (i.e., a variable copied from the possibly 
modified location has a wobbly value, as in DR#451, that need not behave 
consistently like any particular value of its type for subsequent 
operations on it).

I don't think memset_s is any different - it acts on memory as if it were 
volatile, but not atomic.

Similarly, it is valid for functions to read their inputs multiple times 
unless otherwise specified; memcpy has undefined behavior if its inputs 
change concurrently with the call to memcpy (rather than it simply being 
unspecified which value gets copied).

-- 
Joseph S. Myers
joseph@codesourcery.com