Re: Differences between man-pages and libc manual safety markings

[Mark Thompson <mrt-W77v16wj1OVeoWH0uzbU5w@public.gmane.org>]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html