Re: Not intended for use in medical,

[dewar@merv.cs.nyu.edu (Robert Dewar)]

kaz@vision.crest.nt.com (Kaz Kylheku) writes:

> int foo(int x, int y)
>
> {
>       return ((x < y) && x++) && ((x < y) && x++);
> }
[...]
> /*
>  * GCC seems to illegaly optimize foo() by factoring the (x < y)
>  * as a common subexpression ignoring the x++ side effect, e.g:
>  *
>  *     return ((x < y) && x++) && x++;
>  *
>  * A more complex version of this expression has caused a serious
>  * failure in some of my code.
>  */


This is an amazingly comon mistake, and people are always sending
in bogus bug reports to the gcc list complaining about this
particular case.

In fact, as Simon points out, an expresson like the above one is
entirely undefined, and it is quite clear from the ANSI standard
that it is undefined. There is no bug in gcc here, just a bug in
the program, and as usual when programmers put bugs into programs
it can cause serious failures.

The factoring that GCC is doing here is quite legitimate, and indeed
it is *precisely* to allow this kind of optimziation that the standard
declares expressions like this to have undefined semantics.

One important thing that all programmers need to learn is that it is
critical if you are trying to write portable code to know the language
definition. The fact that something happens to work is NOT proof that
your code is correct.

It is possible to write completely portable code in many languages,
including for example C, COBOL and Fortran, but only if you know
the lanuage definition well. In practice, very few C, COBOL or
Fortran programmers know the standard well (typical programmers
for these languages have not even read the standard). One of the
great achievments of Ada 83 was that for the first time since
Algol-60, we had a language where typical professional programmers
owned the standard, and used it at least as a reference work.

Even in Ada 95 this tradition continues (despite the fact that the
Ada 95 standard is much less accessible than the Ada 83 standard, due
to a decision to attempt to be much more precise -- this is always
a tough trade off)

Note also that portability is extremely important in contexts that might
be surprising (such as turning optimization on or off, going to a new
version of the same compiler, or, as in this case, going to a different
compiler on the same machine).