On 03/11/14 05:43, Alexandre Oliva wrote:
The key is external observability, and ordering requirements.
strcpy's sequential specification does not mandate chars to be copied in
any predetermined order, so strcpy is free to reorder and regroup loads
and stores as it sees fit. None of this steps out of its explicit
specification. Writing garbage, however, would step out, but it might
still be allowed under the as-if rule if this couldn't be legitimately
observed, e.g. if any attempt to observe it would invoke undefined
behavior.
On 03/11/14 05:13, Alexandre Oliva wrote:
>
> The way is not specified, but it does not state that it is to write
> something else there before, and doing so is NOT allowed by the as-if
> rule. Consider a function that goes:
>
> for (;;) {
> extern char buffer[];
> strcpy (buffer, "foo");
> signal (SIGUSR1, testme);
> strcpy (buffer, "fool");
> signal (SIGUSR1, SIG_IGN);
> }
>
>
> Now, if the signal handler testme were to inspect buffer[1] (knowing the
> only window in which it may be activated is the above, in a
> single-threaded program), what values could it possibly find there?
> Please justify with quotes from combinations of C and POSIX standards of
> the same vintage you can find. How about buffer[0], and buffer[3]?
>
I disagree with this reasoning, though I am not sufficiently familiar
with the standards involved to argue with it effectively.
However, I do see a more concerning point here: does this argument also
apply to memcpy()? I can't find any language in the standard which
places additional requirements on strcpy() (and which would disallow
implementation as strlen+memcpy, for example).
Given that, does it not follow that the current, released,
implementation of memcpy() in glibc for architectures using a wh64
instruction (alpha, tilepro and tilegx) is entirely wrong?
- Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
