Sender: crough45 AT amc DOT de
Message-Id: <97Aug15.123337gmt+0100.17078@internet01.amc.de>
Date: Fri, 15 Aug 1997 11:35:13 +0100
From: Chris Croughton <crough45 AT amc DOT de>
Mime-Version: 1.0
To: charles AT pentek DOT com
Cc: djgpp AT delorie DOT com
Subject: Re: [Q] expression evaluation order
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Charles Krug wrote:

> On the other hand, I could test my application, using my data, on my
> platform, and see what the results are.  This enables me to do two
> things:

If you don't test your application, you're asking for trouble...

> Broken && || evaluation isn't something you'd catch every time, unlike,
> say, the increment operator.  How often do we write logicals that rely
> on complex function interactions, rather than something that works out
> to:

How much do you test any other part of the code generation?  Do you
do things like:

  for (i = 0; i < ARRAY_SIZE; i++)
  {
    if (array[i] = wanted_value)
      break;
  }
  if (i < ARRAY_SIZE)
    ...

That, which is code which according to the language definition is
perfectly straightforward, very often causes problems with optimisation.
Do you trust the compiler at all?  If so, why?  If not, why trust some 
part more than others?  I have never seen a C compiler which had
broken && or || behaviour, I have seen several with other optimisation
problems, mostly involving if statements and loops.

If you want guarantees, you're out of luck.  No-one can guarantee
all the behaviour of any compiler (or even assembler, and especially
not a CPU).  Ever heard of a CPU which did calculations incorrectly?
Ever seen one which had strange jump behaviour?  Seen an assembler which
calculated jump offset incorrectly sometimes?  I've seen all three.  If
your application is critical, like in aviation or medical equipment,
you'd better test everything very thoroughly and not trust anything.
If it's a game, life's too short to do that.

All anyone can sensibly answer to the original question is "It is
defined behaviour in the specification".  Anything else is at the whim
of deities, cosmic rays, the phase of the moon etc.

It is not helpful to a new programmer to go into all the things which 
might go wrong in some hypothetical system.  What they want to know is
whether it's valid code, and for that the spec. is the only guide.

Chris C