🚀 go-pugleaf

wiecek@ee.ualberta.ca (B. Wiecek) asks, summarized:
[What happens if a compiler's optimizations become detectable
because a program crashes?]

When a C program crashes, it usually did something that, in
terms of the Standard, results in `undefined behavior'; your
dereferencing of a null pointer is a good example.

#    *  Undefined behavior -- behavior, upon use of a nonportable
#	or erroneous program construct, of erroneous data, or of
#	indeterminately valued objects, for which the standard
#	imposes no requirements.	  [From ANSI 1.6, ISO 3.?]

USENET posters have spent many hours flaunting their creativity
in inventing possible uses and illustrations for undefined behavior
(the latter usually in response to the former), but truth is that
the program really can do anything, even retroactively.

It is, in other words, the system as a whole whose behavior is
undefined; not just one particular statement or evaluation.

> What is the standard's standpoint on reordering (non-dependend)
> statements? function calls?

A program with defined behavior---the only kinds for which the
standard guarantees anything about the implementation---must
behave like the abstract machine that the standard describes,
as is detectable by its side effects (I/O and modification of
volatile variables).  This "As-If" rule (which doesn't actually
contain the words "as if"; that's a concept introduced by the
Rationale) is explained in ANSI 2.1.2.3 (ISO 5.1.2.3):

#       The least requirements on a conforming implementation are:
#
#     * At sequence points, volatile objects are stable in the sense
#       that previous evaluations are complete and subsequent evaluations
#       have not yet occurred.
#
#     * At program termination, all data written into files shall be
#       identical to the result that execution of the program according
#       to the abstract semantics would have produced.
#
#     * The input and output dynamics of interactive devices shall
#       take place as specified in 4.9.3.  The intent of these requirements
#       is that unbuffered or line-buffered output appear as soon as
#       possible, to ensure that prompting messages actually appear
#       prior to a program waiting for input.

That certainly allows reordering statements that have no
perceptible dependencies.

If you see C grow as a low-level systems programming language
in a world of unpredictable optimizer development and parallel
hardware, minimalism in what one demands makes sense: in most
cases, you really _want_ your system to go ahead and be as smart
as it possibly can, rather than to penalize all of its users,
all of the time, just so that the error messages make more sense
to some of them, some of the time.  (There's much value in having
a development environment that does this---but not a language
standard.)

Jutta Degener (jutta@cs.tu-berlin.de)