Re: "as-is" rule

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

>> I think you've hit a bug in gcc in this case: "e1 || e2" should not
>> evaluate e2 if e1 evaluates to non-0.
> This is what I always knew: that `e1 || e2 || e3' are evaluated left
> to right.  But I understand the "as-is" rule relaxed that.

No, it did not (and yes Samuel, it's "as-if", not "as-is", sorry).

All the "as-if" rule says is that the assembly code may do anything it
likes as long as the result agrees with some interpretation of the
semantics.  There's a lot of noise around this, but in the end it's
mostly irrelevant, all it says is: don't presume what kind of assembly
will be generated from the source code.  All programming languages admit
the "as-if" rule and other than C none bother to mention it.  C is
special only because it has a "low-level" history and feel which makes
many people assume many things which the semantics does not guarantee
(e.g. ((x-1)+1) may be different from x if x is a pointer to the
beginning of an object, since x-1 is undefined (or was it
"unspecified"?) in this case).
But the C semantics really does guarantee that "e1 || e2" only evaluates
e2 if e1 evaluates to 0, so the "as-if" rule is not the problem.

>> xassert ((row->enabled_p && !row->mode_line_p)
>> ? verify_row_hash (row) : 1);
> If we are dealing with a compiler bug, how can we be sure this
> expression will not hit the same bug?

We can't.

> Anyway, I eventually removed the assertion altogether, so this is a
> moot point now.

Thanks,


        Stefan