Uninitialized Variables

Uninitialized Variables

[Roger Racine]

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 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).

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. 

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?

Roger Racine

Re: Uninitialized Variables

[robert_dewar]

In article <rracine.7.000B4B63@draper.com>,
  rracine@draper.com (Roger Racine) 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 understand  that having an initial
> value takes more memory and more CPU, but so do
> constraint checks.

You miss the philosophical and design objections to junk
initial values. These arguments are familiar so I won't
repeat them in detail here!

> And there could always have been a pragma to allow
> uninitialized variables (akin to pragma SUPPRESS).

Ada 95 of course has a pragma, but it has the opposite
sense, you use pragma Normalize_Scalars if you want
initializations. The intention of this pragma is precisely
to avoid non-determinism. Why is it not enough for you?

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

First, a full analysis at link time of all possible static
flows through a program would be a very heavy burden to
place on a compiler. It is far out of reach of what could
be done in existing implementation frameworks, and I would
have significant efficiency concerns.

Second, requiring warning messages is a big bogus in
anyway. Such requirements are not testable, and not
well-defined. I think it reasonable to let the marketplace
determine the need for warnings.

It is certainly useful for a compiler to do a reasonable
job of detecting obvious cases (try using -gnatwu with
GNAT 3.11p).

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Uninitialized Variables

[Tucker Taft]

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

Re: Uninitialized variables

[Jeffrey Creem]

Gautier wrote:
> Here (trying to to sum up), 3 problems I see with the tactic of
> initializing everything:
> 
>  - useless initializations (i.e. dummy values rewritten later) take
> time and usually _hurt_ performance (think to number crunching with
> huge objects, or frequently used functions with local variables)
>  - useless initializations introduce meaningless code lines
>  - [Dirk] useless initializations prevent detecting bugs that can be
> detected without these initializations (they can be detected by
> combining the Initialize_Scalars pragma and the validity checks)
> 
> My rule is rather to initialize _only_ variables you can give a
> meaningful values.

This is also the approach I follow. It has the added benefit that some 
compilers can now give you warnings about reading from it before you 
assign to it and thus help you find the bug. If one does the typical 
initialize everything to 0 or 'first or something like that then you can 
expect no help from the compiler.

Now in reality, compilers vary in their ability to provide useful 
warnings in this area.

GNAT does a reasonably good job of balancing real warnings in this case 
against false warnings.

Another compiler I use takes a different approach where it seems to warn 
in a lot more cases and thus ends up with a lot more false positives.
It is probably not that bad of an approach if you used this compiler 
from the beginning but with lots of lecagy code the signal to noise 
ratio of these warnings is so poor that I have not really found an 
effective way to make use of the warnings.


Consider the following toy code:

with Text_IO;
procedure Toy is

   I : Integer;
   I_Set : Boolean := False;
   Should_We_Set_I : Character;
   J : Integer;

begin

   Text_Io.Get(Should_We_Set_I);

   if Should_We_Set_I = 'y' then
     I_Set := True;
     I := 1;
   end if;


   if I_Set then
     Text_Io.Put_Line(Integer'Image(I));  -- This is ok
     Text_IO.Put_Line(Integer'image(J));  -- This is bad
   end if;

   J := 1;

end Toy;


GNAT Warns on the line that says This is bad but not on the line that 
says this is ok.

Another compiler I use warns on both (Not posting other compiler here 
only because I have not tested this exact code on it and am making this 
assertion based on similar real code).


Obviously, unless one uses someting like polyspace, a simple compiler 
can't be expected to detect all of these path flow type cases.


The important point here is that if one had a convention that all 
variables should be initialized, no compiler could tell you that you 
were doing something wrong on the "this is bad line".