On Mon, 2014-11-03 at 03:13 -0200, Alexandre Oliva wrote:
> 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.
Ignoring perhaps signal handlers for a second, is there anything in C90
that is not a sequential program?
> There's nothing specifically sequential about it, nor is it only
> before/after invocation: the standard states what the function does,
Yes. And how do function definitions work? You specify before and
after. Because you couldn't reasonably specify how it's implemented,
nor would you want to. So it has a precondition, and it has a
postcondition.
Just think about the sorting function analogy I mentioned, will you?
> and
> if it does something else that conflicts with the specification and is
> observable, it diverges from the specification. Right?
Sure, but we still don't agree what is specified, so this sentence here
doesn't add anything.
>
> > especially if all it does is write to the destination
> > string, in some way.
>
> The way is not specified,
Exactly. Period. Can it set bit by bit? Sure it can, why not?
But you would end up with the same kind of "garbage" as you call it. Or
you could write by adding 1's until it reaches the final value.
> 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 find it very telling that you completely ignored the sorting function
analogy I mentioned. Here is the paragraph again, from my previous
email:
Would you make any assumptions about the stores performed by a sorting
function that is specified to take an array, and return with the array's
elements being sorted? Would you require it to only write finally
sorted data out, or would you allow it to use the array as scratch space
too? I guess the latter. And the same applies to strcpy, you don't
want to restrict whether it copies forwards or backwards, for example.
And you don't have to for sequential code.
Unless you reply to that, I won't spend further time discussing with
you.
>
> > 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.
Precisely, it means that volatile accesses have to executed as-if by the
abstract machine. So, if we have volatile for that, do you see that
something of this won't hold for nonvolatile?
> 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.
Those examples don't apply here, and I said before why, and you didn't
dispute that, so I'm not writing that again.
> > They didn't specify rules for multi-threaded execution, did they?
>
> Exactly!
Good. Because then effects of multi-threaded execution are not
specified. So there's no constraints.
--
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
