From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 4 Jan 93 15:28:27 GMT
From: agate!spool.mu.edu!uwm.edu!caen!hellgate.utah.edu!peruvian.cs.utah.edu!ma
twood@ucbvax.Berkeley.EDU  (Mark Atwood)
Subject: Re: An Ada Program Does What It Says?
Message-ID: <1993Jan4.082827.11773@hellgate.utah.edu>
List-Id: <comp.lang.ada>

In article <9301031530.AA17787@ajpo.sei.cmu.edu>, SAHARBAUGH@ROO.FIT.EDU writes
:
>I searched B&M's book and noted each example program whose 
>output is "indeterminate" or "implementation dependent".  I 
>noted the page number on which the answer appears.  

(deleted)

>My warning stands.  Ada code looks deceptively readable.  The 
>reader must understand the language translator and the 
>runtime environment to be able to correctly read an Ada 
>program.

I just finished reading those books, and yes there do seem to be a lot of
indeterminate and compiler dependent "thing" in the Ada standard.  A co-
worker and I discussed it for a while and made the observation that probably
every language has these "gotcha"'s, they just aren't as well documented
or understood.

Stuff like expression ordering, floating point representation, concurency,
etc, will always be indeterminate.

Not to trigger yet another C vs Ada flamefest, but this expression in
C is a classic example...

  r = (i++ == ++i)

-- 
Mark Atwood                  :: Being a kitten is it's own excuse.
matwood@peruvian.cs.utah.edu :: 
The University has enough problems without being blamed for mine.