🚀 go-pugleaf

In article <4c4h39$29n@news.cs.tu-berlin.de>, jutta@cs.tu-berlin.de says...
 >
 >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.

True, my example wasn't good in the sense that it 
produces undefined behaviour, so it doesn't matter what the program
does anymore.


 >> 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.

Thank you, that is the information I've been looking for.

 >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.)

Agreed.
Just couldn't recall if there was restriction placed on reordering
statements.

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

Regards,

B. Wiecek
wiecek@ee.ualberta.ca
--