Uninitialized variables (was: Re: private types)

[dirk@apollo.cs.kuleuven.ac.be (Dirk Craeynest)]

[This thread really is about uninitialized variables now, so I changed
the subject...]

In article <e_mdncFXrsg5wobZnZ2dnUVZ_t2dnZ2d@megapath.net>,
Randy Brukardt <randy@rrsoftware.com> wrote:
>So I recommend initalizing everything (or assigning it immediately
>after the begin) that could be significant to performance.

We did (and do) feel this is not a good approach, at least not when
using GNAT or another compiler that supports something like the pragma
Initialize_Scalars and enhanced validity checking.

For much more about uninitialized variables in Ada code, the following
paper might be useful:

  "Exposing Uninitialized Variables: Strengthening and Extending
  Run-Time Checks in Ada" [1],
  Robert Dewar, Olivier Hainque, Dirk Craeynest, and Philippe
  Waroquiers,
  In "Proceedings of the 7th International Conference on Reliable
  Software Technologies - Ada-Europe 2002" [2], Vienna, Austria,
  June 17-21, 2002, Johan Blieberger and Alfred Strohmeier (Eds.),
  volume 2361 of Lecture Notes in Computer Science, pages 193-204,
  Springer-Verlag, 2002.

The conclusion of that paper contains our recommendation:

---start-quote---

5.3 Impact of Usage of Initialize Scalars on How to Program

There is a trend in programming guidelines to "force" initializing
everything at declaration resulting in code like:

  B : Natural := 0;

  if .... then
    B := 5;
  else
    B := 8;
  end if;

The difficulty with such an approach is that the initial value is
meaningless. If this value is used accidentally, the results are
potentially just as wrong as the use of an uninitialized value, and
furthermore, the explicit initialization precludes the approach we
have described in this paper, and thus may introduce bugs that are much
harder to find and fix. The automatic initialization under control of
the compiler using Initialize Scalars is a far preferable approach.

We therefore recommend that when a scalar is declared, the programmer
should avoid initializing it if the code is supposed to set the value
on all paths.  It is better to let Initialize Scalars + gnatVa detect
the bug in the code logic rather than trying to deal with meaningless
initial values. Even for safety-critical programs, we can first compile
with Initialize Scalars + gnatVa + invalid values and then, if needed,
field the code with Initialize Scalars + all zero values (if it is the
case that zero values give the code a better chance of avoiding
seriously improper behavior).

---end-quote---

The GNAT manuals provide more information on GNAT's pragma
Initialize_Scalars [3] and on enhanced validity checking [4].
Reference [3] mentions:

---start-quote---

Note that pragma Initialize_Scalars is particularly useful in
conjunction with the enhanced validity checking that is now provided
in GNAT, which checks for invalid values under more conditions.
Using this feature (see description of the -gnatV flag in the users
guide) in conjunction with pragma Initialize_Scalars provides a
powerful new tool to assist in the detection of problems caused by
uninitialized variables. 

---end-quote---

We can assure everyone that from a developers and testers point of view
the combination of Initialize_Scalars and enhanced validity checking is
indeed "particularly useful".

References:
[1] <http://www.cs.kuleuven.be/~dirk/papers/ae02cfmu-paper.pdf>
[2] <http://www.springer.de/cgi/svcat/search_book.pl?isbn=3-540-43784-3>
[3] <http://www.adacore.com/wp-content/files/auto_update/gnat-unw-docs/html/gnat_rm_2.html#SEC48>
[4] <http://www.adacore.com/wp-content/files/auto_update/gnat-unw-docs/html/gnat_ugn_4.html#SEC47>

Dirk
Dirk.Craeynest@cs.kuleuven.be (for Ada-Belgium/-Europe/SIGAda/WG9 mail)

*** 11th Intl.Conf.on Reliable Software Technologies - Ada-Europe'2006
*** June 5-9, 2006 ** Porto, Portugal ** http://www.ada-europe.org ***