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=-0.9 required=3.0 tests=BAYES_00,TO_NO_BRKTS_PCNT
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: 27 Oct 92 01:26:58 GMT
From: eachus@mitre-bedford.arpa  (Robert I. Eachus)
Subject: Re: Uninitialized subtype variables
Message-ID: <EACHUS.92Oct26202658@Dr_No.mitre.org>
List-Id: <comp.lang.ada>

In article <61435@mimsy.umd.edu> alex@cs.umd.edu (Alex Blakemore) writes:

   though this is a nice trick, it hurts portability.

   an erroneous program could pass through rigorous testing without a hint of
   the inherent problems.  They could then show up seemingly in random
   places in another compiler.  At least, without this trick there is a decent
   chance you will find the error - with or without optimizing the checks away.

   even though this is allowed by Ada83.  I would prefer the compiler
   did not initialze variables that I did not initialize.

   It would be nice as a compilation option to choose between allowing
   the optimizer to assume all variables were in range (fast code) and
   disallowing check removal which could depend on unitialized
   variable being in range (safe code).  This is not the same as
   suppressing all checks.

   Hmmm!  The compiler we did this on notified the user in a warning
message.  I used to go through them religiously and find the ones
where I goofed, and the ones where the compiler goofed (couldn't
figure out that all paths were safe even with sufficient information).
The latter category shrank quickly, and the remainder--it was okay but
the compiler didn't have the information to know--accounted for less
than 30% of the uninitialized scalar variable warnings.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...