[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "as-is" rule
From: |
Stefan Monnier |
Subject: |
Re: "as-is" rule |
Date: |
Wed, 30 Nov 2011 14:09:51 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux) |
>> 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