comp.lang.ada
 help / color / mirror / Atom feed
From: stt@houdini.camb.inmet.com (Tucker Taft)
Subject: Re: Uninitialized Variables
Date: 1999/01/25
Date: 1999-01-25T00:00:00+00:00	[thread overview]
Message-ID: <F650rE.Cq5.0.-s@inmet.camb.inmet.com> (raw)
In-Reply-To: rracine.7.000B4B63@draper.com

Roger Racine (rracine@draper.com) wrote:

: One of the few areas where Ada programs exhibit non-deterministic behavior 
: (i.e. different behavior for different runs) is when variables are not set 
: before their use.   

: I am curious as to why the language designers did not think this was 
: sufficiently common enough of an error to protect against it.  

I don't know the Ada 83 history on this.  However, simply default
initializing all scalars to something like zero has its own problems,
because it can make it less clear whether the default value is the
desired initial value, or the programmer forgot to properly set the
value.  Initializing pointers by default to null has somewhat the
same problem, but less so, since any dereference of a null pointer
would be caught, whereas any use of a default scalar value would
probably not be caught.

In any case, Ada 95 does include a pragma "Normalize_Scalars" which 
forces the implementation to initialize all scalars to some unspecified 
value, ideally to a value outside of their declared range.  The goal 
here is to create reproducibility, without allowing the programmer 
to "shirk" their responsibility of initializing the variable properly.

: ... I understand 
: that having an initial value takes more memory and more CPU, but so do 
: constraint checks.  And there could always have been a pragma to allow 
: uninitialized variables (akin to pragma SUPPRESS).

I guess I agree that it is a relatively small price to pay, but it did
not seem like something we could insert during the Ada 9X revision.  We
wanted performance to be compatible with Ada 83 as well!  Certainly
Bob Duff, a member of the Ada 9X design team, would agree with your 
suggestions.  Note that in Ada 95 we did change the use of an uninitialized 
variable into a "bounded error" rather than "erroneous."  Even this change 
drew some protests from implementors because of the potential performance 
effects.

: By the way, I would be happy with a mechanism at link time that  only 
: complained about (or implicitly created initial values for) data that was 
: determined might be used before being set. 

We have recently added to our Ada 95 front end detection of potentially
uninitialized local variables.  Detecting potentially uninitialized 
global variables would require some kind of link-time detection.

: The problem is that different environments exhibit different behavior.  Some 
: environments put zeros in all of RAM as part of initialization.  This 
: sometimes masks the problem (which is fine if portability is not a concern).  
: Some put zeros in all static (non-stack, non-heap) variables.  Some even allow 
: the user to specify the value to be put in RAM.  And some do nothing at all.

: Does anyone know why there is not at least a required link-time warning 
: message for variables possibly used before being set?

Requiring specific warnings is generally treading on thin ice from
a language specification point of view.  Even specifying the form
of error messages is difficult.

This is really more of a quality-of-implementation issue, and not
very easy to legislate via the language standard.

: Roger Racine

--
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA




  reply	other threads:[~1999-01-25  0:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-01-25  0:00 Uninitialized Variables Roger Racine
1999-01-25  0:00 ` Tucker Taft [this message]
1999-01-25  0:00 ` robert_dewar
  -- strict thread matches above, loose matches on Subject: below --
2006-03-13 19:58 private types ada_student
2006-03-17  4:33 ` Justin Gombos
2006-03-17  5:17   ` Brian May
2006-03-18  1:17     ` Randy Brukardt
2006-03-18  8:39       ` Uninitialized variables (was: Re: private types) Dirk Craeynest
2006-03-18 14:06         ` Gautier
2006-03-18 14:36           ` Uninitialized variables Jeffrey Creem
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox