On Nov 1, 2014, Torvald Riegel <triegel@xxxxxxxxxx> wrote:
> On Sat, 2014-11-01 at 16:32 -0200, Alexandre Oliva wrote:
>> That goes both ways. While strcpy coded for current standards might
>> wish to make such optimizations, old code written for earlier standards
>> that did not make allowances for the proposed strcpy optimization would
>> break.
> Which earlier standard are you referring to?
I think going back to C90 would do.
> Did any old standard have strcpy as something else than a
> sequentially-specified function?
Your question needs to be rephrased to take out the “sequentially-”
noise that distorts your reasoning into some kind of tunnel vision.
There's nothing specifically sequential about it, nor is it only
before/after invocation: the standard states what the function does, and
if it does something else that conflicts with the specification and is
observable, it diverges from the specification. Right?
> especially if all it does is write to the destination
> string, in some way.
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]?
> It is not specified as operating on volatile-qualified data
volatile doesn't mean what you appear to suggest it does.
volatile means operations are not to be reordered, combined or otherwise
optimized. It does not mean writing garbage to a global variable is
allowed just because it's not volatile, any more than it means the as-if
rule allows a function to release a lock on entry and take it again
before returning. What if printf were to do that on the lock that
controls stdout? Surely that would be observable, as much as the
contents of the buffer within the signal handler.
> They didn't specify rules for multi-threaded execution, did they?
Exactly!
I don't think you can push the as-if rule as far as you suggest when it
comes to global symbols, or other symbols whose pointers have escaped.
POSIX memory synchronization requirements might make speculative writes
defensible for asynchronicity arising from threads, but from async
signals?
I don't see allowances for that, do you?
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
--
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
