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: 25 Oct 92 11:37:42 GMT
From: math.fu-berlin.de!news.netmbx.de!Germany.EU.net!mcsun!sunic!seunet!enea!s
ommar@uunet.uu.net  (Erland Sommarskog)
Subject: Re: Uninitialized subtype variables
Message-ID: <1992Oct25.113742.1164@enea.se>
List-Id: <comp.lang.ada>

Robert I. Eachus (eachus@Dr_No.mitre.org) writes:
>     One slight addition to Tucker's list.  Another alternative that a
>compiler can take is to choose to initialize the variable instead of
>doing the check.  This turns out to be a pretty "neat" trick when the
>compiler back-end eliminates assignments of unused values.  If the
>initial value is never used (and the compiler can figure it out) the
>extra assignment is eliminated, otherwise the assignment is usually
>cheaper than the check (for scalars).

Sounds indeed palatable, but...

The variable is no more initialized because the compiler assigned
a value to it, and your program may still behave in mysterious
ways. And since you never stumble on a range check you're likely
to be even more confused.

Or even worse, you develop with the compiler initialization, con-
sciounsly or by mistake, everything works fine, until the day you
port to new compiler which never initializes variables and what used
to be a fine working program is now an inferno of unexplainable random
behaviour.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
N{r busen hejdar sin st}lskodda klack en centimeter innan din t}h{tta,
och v{ser "n{sta g}ng...", det {r d} du f}tt andrum till varnagel.