> Mike Stump wrote:
>> Paul Schlie wrote:
>> - If the semantics of an operation are "undefined", I'd agree; but if
>> control is returned to the program, the program's remaining specified
>> semantics must be correspondingly obeyed, including the those which
>> may utilize the resulting value of the "undefined" operation.
>
> I am sorry the standard disagrees with you:
>
> [#3] A program that is correct in all other aspects,
> operating on correct data, containing unspecified behavior
> shall be a correct program and act in accordance with
> 5.1.2.3.
>
> :-( Maybe you just mean that you'd like it if the compiler should
> follow the remaining semantics as best it can, on that point, I'd agree.
Maybe I didn't phrase my statement well; I fully agree with the cited
paragraph above which specifically says a program containing unspecified
behavior "shall be a correct program and act in accordance with
5.1.2.3". Which specifies program execution, in terms of an abstract machine
model, which correspondingly requires:
[#2] ... At certain specified
points in the execution sequence called sequence points, all
side effects of previous evaluations shall be complete and
no side effects of subsequent evaluations shall have taken
place.
[#3] In the abstract machine, all expressions are evaluated
as specified by the semantics. An actual implementation
need not evaluate part of an expression if it can deduce
that its value is not used and that no needed side effects
are produced ...
Therefore regardless of the result of an "undefined" result/operation at
it's enclosing sequence point, the remaining program must continue to abide
by the specified semantics of the language.
> Robert Dewar writes:
> You are forgetting the "as if" semantics that is always inherent in
> the standard. So after an operation with an undefined result, we can
> do anything we like with the value, since it is "as if" the operation
> had produced that value. So for example, if we skip an operation because
> we know it will overflow, and end up using uninitialized junk in a register,
> it is "as if" that undefined operation produced the particular uninitialized
> junk value that we ended up with.
>
> So the above is inventive but wrong.
No, as above, the standard clearly requires that the side-effects of an
undefined operation be effectively bounded at it's enclosing sequence
points. Therefore any optimizations performed beyond these bounds must be
"as if" consistent with any resulting stored value/state side effects which
may have resulted from an operation's undefined behavior.
Therefore clearly, subsequent evaluations/optimizations must comply with
whatever logical state is defined to exist subsequent to an implementation's
choice of an undefined behavior past it's delineated sequence point if
logical execution is allowed to proceed past them.
Therefore clearly:
- an optimization which presume a value which differs from the effective
stored value past a sequence point may result in erroneous behavior; which
as would be the case in the example I provided.
- an optimization which presumes the execution state of a program does not
proceed past a sequence point. but in fact does, may result in erroneous
behavior; which would be the case if NULL pointer comparisons were optimized
away presuming an earlier pointer dereference would have prevented execution
from proceeding past it's enclosing sequence point if in fact it does not.
> Dale Johannesen writes:
> You are wrong, and this really isn't a matter of opinion. The standard
> defines exactly what it means by "undefined behavior":
>
> 3.4.3 1 undefined behavior
> behavior, upon use of a nonportable or erroneous program construct or
> of erroneous data, for which this International Standard imposes no
> requirements
>
> 2 NOTE Possible undefined behavior ranges from ignoring the situation
> completely with unpredictable results, to behaving during translation or
> program execution in a documented manner characteristic of the environment
> (with or without the issuance of a diagnostic message), to terminating a
> translation or execution (with the issuance of a diagnostic message).
- as above, the logical side effects of an undefined behavior (what ever
it's defined to be by an implementation) are clearly logically constrained
to within the bounds of the it's enclosing sequence points.
