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: 22 Oct 92 13:46:07 GMT
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!wupost!micro-heart-of-gold.m
it.edu!bu.edu!inmet!spock!stt@ucbvax.Berkeley.EDU  (Tucker Taft)
Subject: Re: Uninitialized subtype variables
Message-ID: <1992Oct22.134607.17193@inmet.camb.inmet.com>
List-Id: <comp.lang.ada>

In article <1992Oct21.234759.24972@beaver.cs.washington.edu> 
  pattis@cs.washington.edu (Richard Pattis) writes:

>I cannot find anything in the LRM (mostly around 3.2.1) for Ada that says
>after elaborating 
>   X : NATURAL;
>X's value is guaranteed to be >= 0. Is this in fact correct? Is there even a
>guarantee that the bit pattern it contains can be interpreted as a
>legal INTEGER?

No.  Any use of the value of an uninitialized scalar object is erroneous (i.e.
completely unpredictable effect) in Ada 83 (RM 3.2.1(18)).  
In Ada 9x we are proposing that such a use be a 
"bounded error" which means that no random memory
may be trashed nor may your disk be erased simply as a 
result of using the value
of an uninitialized scalar.

>Now, suppose I also declared PROCEDURE P (N : NATURAL); A smart compiler
>could avoid checking the parameter constraint when calling P(X). But this coul
d
>lead to some interesting errors if X truly contained a negative value from its
>(lack of) initialization.

Some Ada 83 optimizers presume all variables are within their subtype
at all times, whereas others presume only explicitly initialized variables
are within their subtype, plus those where data flow guarantees
some initialization has taken place.  It depends somewhat on the
philosophy of the authors of the optimizer -- whether they believe
erroneousness is uncommon and should be ignored (as is allowed
by the rules in the 83 RM), or is common and should be accommodated.

For Ada 9X we are trying to formulate rules which will allow optimizers
to eliminate most constraint checks based on declared subtypes,
but will still prevent random stores to memory, or random jumps.
One approach is to require constraint checks on array component assignments
(and similar memory-altering operations) even if 
subtype information implies the check can't fail,
but be more permissive elsewhere.  Of course if the data flow
analysis "proves" that even after ignoring the subtype information,
the index is within range, then the constraint check can still
be eliminated.

>Any comments?

It's a bag of worms, but we are still trying to do something about it ;-).
Uninitialized scalar variables are one of the few "holes" left in the
Ada safety net, and it would be nice to somehow narrow the hole a bit.
Of course, some kind of "pragma SUPPRESS" should be provided to rip
it open again on user request, but we would like the RM to specify
essentially "safe" semantics as the default, presuming it can
be done without unduly complicating the semantics nor significantly 
hurting code quality.

>------------------------------------------------------------------------------
>  Richard E. Pattis			"Programming languages are like
>  Department of Computer Science	 pizzas - they come in only "too"
>    and Engineering			 sizes: too big and too small."


S. Tucker Taft    stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138