Gabriel Dos Reis wrote:
and it should also be able to take your life. Do you want it to actually
do it? If yes, I suggest you create your own compiler that does that
and leave us work on a compiler that does something more positive.
-- Gaby
Obviously no one programs a compiler to deliberately have disastrous
behavior in an undefined situation. However, if you are interested in
the best possible code from an efficiency point of view, the compiler
is allowed to assert that the overflow cannot take place, and then make
all logical deductions about control flow etc that come from this
assumption. As I showed with my password example, this can have unexpected
results.
The standard allows this broad view of undefined precisely so that
undefined behavior does not damage generated code quality.
Of course a compiler is free to take a much narrower view of undefined,
but this should be done with some clear knowledge of the trade offs in
terms of damaging code efficiency.
I do think that the Ada 95 approach of replacing undefined behavior
(called erroneous execution in Ada) with the notion of a bounded
error is a good one. This allows the effects to be bounded without
any undue effect on quality of code.
The forward and backward propagation of the assumption of no undefined
behavior can indeed have surprising effects, and as compiler optimizers
get more sophisticated and more global, the effects become more unbounded.
Informally I think you would like to say something like "no backward
propagation at all, and no forward propagation if it causes results that
are too surprising to the user", but even the first part of this is very
difficult to formalize, and the second part is impsosible to formalize.
