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 17:38:11 GMT
From: bloom-picayune.mit.edu!enterpoop.mit.edu!snorkelwacker.mit.edu!tamsun.tam
u.edu!cs.utexas.edu!convex!sercely@bloom-beacon.mit.edu  (Ron Sercely)
Subject: Re: Uninitialized subtype variables
Message-ID: <1992Oct22.173811.5455@convex.com>
List-Id: <comp.lang.ada>

In article <1992Oct21.234759.24972@beaver.cs.washington.edu> pattis@cs.washingt
on.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?
>
>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.
>
>Any comments?
>
>------------------------------------------------------------------------------
>  Richard E. Pattis

You are correct.  The elaboration of x: natural; 
makes NO guarantee about the bit pattern in the memory associated with x,
and that this does indeed lead to interesting errors, as compilers do often
optimize away checks because the "know" that the value must be positive.

The bottom line is that programs that read from un-initialized variables
are erroneous.  Some compilers will warn you about potential use before
assignment.

Ron Sercely