From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,c1131ea1fcd630a
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: To Initialise or not
Date: 1996/04/30
Message-ID: <DqnH5L.4r3@world.std.com>#1/1
X-Deja-AN: 152135571
references: <318508FE.204B@sanders.lockheed.com>
 <3184E9CE.5C7A@lmtas.lmco.com> <DqnGoz.10v@world.std.com>
organization: The World Public Access UNIX, Brookline, MA
newsgroups: comp.lang.ada
Date: 1996-04-30T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <DqnGoz.10v@world.std.com>,
I wrote:

>Ideally, the language would require detection of uninitialized
>variables, and an uninitialized pointer would be different from a null
>pointer.  The reason for not doing that are for efficiency, of course.

By the way, it always seemed silly to me that Ada 83 required
default-initialization of pointers to null, but integers are totally
undefined by default.  The idea was that dereferencing an uninitialized
pointer is *really* bad, whereas reading an uninitialized integer is
only mildly bad.  But that's not true.  "Ptr.all := 1;" and
"Array_Var(I) := 1;" are both equally bad in that they can both
overwrite arbitrary storage (if Ptr and I are not undefined).  Ada 95
fixes the array reference problem -- it can no longer overwrite
arbitrary storage.

- Bob