This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: ctermid: return string literal, document MT-Safety pitfall
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Torvald Riegel <triegel at redhat dot com>, Florian Weimer <fweimer at redhat dot com>, <libc-alpha at sourceware dot org>
- Date: Fri, 21 Nov 2014 17:17:01 +0000
- Subject: Re: ctermid: return string literal, document MT-Safety pitfall
- Authentication-results: sourceware.org; auth=none
- References: <ortx2b8l2k dot fsf at free dot home> <54620F80 dot 3030001 at redhat dot com> <ortx22ak52 dot fsf at free dot home> <5465EF19 dot 5040802 at redhat dot com> <1415971681 dot 4535 dot 326 dot camel at triegel dot csb> <54660803 dot 1050809 at redhat dot com> <1415973961 dot 4535 dot 331 dot camel at triegel dot csb> <or4mu1iv0p dot fsf at free dot home> <1416217460 dot 4535 dot 361 dot camel at triegel dot csb> <or8uj8kv1m dot fsf at free dot home> <1416435060 dot 3539 dot 104 dot camel at triegel dot csb> <orlhn4j3y2 dot fsf at free dot home>
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
- References:
- ctermid: return string literal, document MT-Safety pitfall
- Re: ctermid: return string literal, document MT-Safety pitfall
- Re: ctermid: return string literal, document MT-Safety pitfall
- Re: ctermid: return string literal, document MT-Safety pitfall
- Re: ctermid: return string literal, document MT-Safety pitfall
- Re: ctermid: return string literal, document MT-Safety pitfall
- Re: ctermid: return string literal, document MT-Safety pitfall
- Re: ctermid: return string literal, document MT-Safety pitfall
- Re: ctermid: return string literal, document MT-Safety pitfall
- Re: ctermid: return string literal, document MT-Safety pitfall
- Re: ctermid: return string literal, document MT-Safety pitfall
- Re: ctermid: return string literal, document MT-Safety pitfall