[Q] To initialise or not.

[Q] To initialise or not.

[JP Thornley]

We are currently looking at revision of the Ada coding standards 
(probably based closely on the Ada Quality and Style Guidelines as 
advised elsewhere).

However the issue of whether or not to require all scalar objects to be 
initialised has generated a substantial discussion without yet reaching 
a clear conclusion.  The Ada Quality and Style Guidelines are silent on 
this issue, so I would be interested in what other Ada users have found 
and what recommendations they would make.

Briefly, the argument for initialising everything is predictability of 
operation (by avoiding a read of an uninitialised value).  The 
argument against is that giving everything an initial value obscures the 
fact that some objects *should* be initialised (and the initial value 
has some significance) and other initialisations are there simply to 
follow the rule (and the value has no particular significance).

(Note that some projects will be using Ada 83 for some time yet, so 
pragma Normalize_Scalars isn't an option).

Thanks in advance.

Phil Thornley

-- 
------------------------------------------------------------------------
| JP Thornley    EMail jpt@diphi.demon.co.uk                           |
------------------------------------------------------------------------

Re: [Q] To initialise or not.

[Robert I. Eachus]

In article <484274071wnr@diphi.demon.co.uk> JP Thornley <jpt@diphi.demon.co.uk> writes:

  > ...However the issue of whether or not to require all scalar
  > objects to be initialised has generated a substantial discussion
  > without yet reaching a clear conclusion...

  > Briefly, the argument for initialising everything is
  > predictability of operation (by avoiding a read of an
  > uninitialised value).  The argument against is that giving
  > everything an initial value obscures the fact that some objects
  > *should* be initialised (and the initial value has some
  > significance) and other initialisations are there simply to follow
  > the rule (and the value has no particular significance).

    And if you put in a junk initial value, you override the detection
of potentially erroneous uses by the compiler! Compilers can't catch
all cases of use of uninitialized variables, but there are several
that do pretty well.

    Require meaningful initial values where possible, and leave it at
that.

    The alternative is to use lots of declare blocks to put meaningful
initial values on variables, which can then be declared closer to
first use.  I have never found this to be a good alternative.
Although in Ada it is an occasionally necessary for non-scalars.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: [Q] To initialise or not.

[Ken Garlington]

JP Thornley wrote:
> 
> However the issue of whether or not to require all scalar objects to be
> initialised has generated a substantial discussion without yet reaching
> a clear conclusion.  The Ada Quality and Style Guidelines are silent on
> this issue, so I would be interested in what other Ada users have found
> and what recommendations they would make.

Section 5.9.6 of the Ada 95 Quality and Style Guide does discuss initialization
issues. Some of the recommendations there are also applicable to Ada 83.

> (Note that some projects will be using Ada 83 for some time yet, so
> pragma Normalize_Scalars isn't an option).

Actually, Normalize_Scalars cannot be used to ensure that objects are
initialized before use; in fact, it definitely cannot be used to ensure
objects have _valid_ values before use!

Re: [Q] To initialise or not.

[Robert A Duff]

In article <3180CF00.17D5@lmtas.lmco.com>,
Ken Garlington  <garlingtonke@lmtas.lmco.com> wrote:
>Actually, Normalize_Scalars cannot be used to ensure that objects are
>initialized before use; in fact, it definitely cannot be used to ensure
>objects have _valid_ values before use!

True, but it ensures the same sort of predictability that the "always
explicitly initialize" rule does.  Hopefully, you get a run-time error
with Normalize_Scalars.  Better than nothing ;-).

- Bob

Re: [Q] To initialise or not.

[Robert Dewar]

Ken Garlington said

"Actually, Normalize_Scalars cannot be used to ensure that objects are
initialized before use; in fact, it definitely cannot be used to ensure
objects have _valid_ values before use!"

That's half wrong and half right. The first half is wrong, NS definitely
causes all scalars to be initialized before use. The second half is right,
it is (deliberately) not the case that NS requires valid values.

The whole idea is to guarantee predictability by initializing everything
to a known and consistent value, WITHOUT necessarily providing a valid
value on which the proram could (incorrectly) depend.

Re: [Q] To initialise or not.

[Robert A Duff]

In article <dewar.830583555@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>The whole idea is to guarantee predictability by initializing everything
>to a known and consistent value, WITHOUT necessarily providing a valid
>value on which the proram could (incorrectly) depend.

Right.  In fact, the compiler is *supposed* to initialize to an
*invalid* value, whenever possible, in order to cause an exception.
The reason this is not *required* is that some types don't have any
invalid values.  For example, type Integer likely uses up all the
available bits for representing valid values, and we didn't want to
require the compiler to store an extra bit in those cases.  Requiring
that would complicate the compiler, cause inefficiency, and cause
trouble when interfacing to other languages.

Another example: in a packed array of Booleans, you get one bit per
component, which doesn't leave any extra bits for invalid values.  A
stand-alone Boolean variable, on the other hand, will probably get 8
bits, or 32 bits, so pragma Normalize_Scalars will cause "X: Boolean;"
to be initialized to some bit pattern that represents neither True nor
False.

- Bob

Re: [Q] To initialise or not.

[Theodore E. Dennison]

JP Thornley wrote:
> 
> We are currently looking at revision of the Ada coding standards
> (probably based closely on the Ada Quality and Style Guidelines as
> advised elsewhere).
> 
> However the issue of whether or not to require all scalar objects to be
> initialised has generated a substantial discussion without yet reaching
> a clear conclusion.  The Ada Quality and Style Guidelines are silent on
> this issue, so I would be interested in what other Ada users have found
> and what recommendations they would make.

I suspect it is silent on this issue, because the Ada (83) LRM is 
NOT silent on the issue. Section 3.2.1(18) reads:
"The execution of a program is erroneous if it attempts to evaluate a
 scalar variable with an undefined value."

In pracitice you don't even need to throw words like "erronious" around,
because a program that reads from an uninitialized variable generally
won't work. 

I don't see the overriding need to write a procedure to forbid every
possible erronious practice. But if you do, I'd just phrase it to 
forbid the situation above- "The program shall not attempt to evaluate
a scalar variable that has not been initialized".

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: [Q] To initialise or not.

[Robert A Duff]

In article <318109B1.3B54AFBF@escmail.orl.mmc.com>,
Theodore E. Dennison <dennison@escmail.orl.mmc.com> wrote:
>I suspect it is silent on this issue, because the Ada (83) LRM is 
>NOT silent on the issue. Section 3.2.1(18) reads:
>"The execution of a program is erroneous if it attempts to evaluate a
> scalar variable with an undefined value."

Yes, but how do you ensure that your program is not erroneous in this
way?  One way, which the earlier poster is asking about, is to have a
rule that all variables will be explicitly initialized on the
declaration.  The question is: does this coding convention help or hurt?
On the one hand, it prevents the erroneous cases.  On the other hand, it
causes variables to be initialized to bogus values, and what *would*
have been an erroneous read of an uninitialized variable, is, instead, a
read of a wrong value from that variable.

My personal coding convention is to *not* initialize variables if I know
they will be properly initialized later.  E.g.:

    declare
        X: Integer;
    begin
        if ... then
            X := 12;
        else
            X := 13;
        end if;
        ... -- some reads of X

In the above, I would *not* write "X: Integer := 0;".

The problem is, of course, that if you make a mistake, the program will
do who-knows-what.  But I still think it makes the code more readable to
avoid that bogus initial value of 0.

I would very much like to see compilers check these cases at run time.

I was going to suggest pragma Initialize_Scalars, but the original
poster said Ada 95 features are out of the question.

As an aside, I always write ":= null;" when I want to *rely* on the
initial value of a pointer, even though I know that pointers are always
default-initialized to null.

- Bob

Re: [Q] To initialise or not.

[Thorsten Behrens]

Captain, bei Sternzeit Fri, 26 Apr 1996 18:55:28 GMT empfingen wir folgende
Nachricht von Robert A Duff:

>...
> My personal coding convention is to *not* initialize variables if I know
> they will be properly initialized later.  E.g.:
> 
>     declare
>         X: Integer;
>     begin
>         if ... then
>             X := 12;
>         else
>             X := 13;
>         end if;
>         ... -- some reads of X
> 
> In the above, I would *not* write "X: Integer := 0;".

This initialization would indeed make no sense. But in the example above
(and in many similar cases) you could have used:

   declare
     X :  INTEGER
       := 12;
       -- 'X' is initialized to 12 here because ...
       -- It will be changed to '13' under the following circumstances ...
       -- in the code piece following.
   begin
     if not ... then
       X := 13;
     end if;
     ... -- some reads of 'X'

Of course, you would have to write some additional comment. But may be this
adds some details to your source some other people reading it may need to
get a deeper understanding (of course not in this simple example).

I tend to give all my declarations some initial value (if possible) _and_
an initial comment (giving a shorter or longer text about its usage and
the background of this variable). In my eyes this saves me from having
non-initialized variables (causing errors which are sometimes nasty to
find) and it saves people reviewing my sources from wasting too much time
to guess what I was thinking when "inventing" a variable (normally, I would
not use a variable called 'X', but instead would have called it
'Some_Meaningful_Name').

BTW, a former colleague of mine called me a 'secretary' when he found too
many comments in my source code. That the other side of the medal.

>...
> I would very much like to see compilers check these cases at run time.

You could use some kind of software review tools for this.

-----------------------------------------------------------------------------
- Thorsten Behrens      ///    Voice : +49 421 351252                       -
- Buddestr. 39      \\\///     e-mail: thorsten.behrens@dorunth.hb.north.de -
- 28215 Bremen       \XX/                                                   -
-----------------------------------------------------------------------------
- aka Aggli 'if it moves, kill it' the Fist                                 -
-----------------------------------------------------------------------------

Re: [Q] To initialise or not.

[Robert Dewar]

Thorsten says

"   declare
     X :  INTEGER
       := 12;
       -- 'X' is initialized to 12 here because ...
       -- It will be changed to '13' under the following circumstances ...
       -- in the code piece following.
   begin
     if not ... then
       X := 13;"

recommending that all variables be initialized.

I am not sure I like this. Now you replae the possible error of not
initializing a variable with using a junk value (here using a 12
when a 12 is not intended). Furthermore, messing around with conditions
and putting not's in front of them seems to me to be undesirable.

I am not saying that this is never a good idea, but personally I prefer
not to initialize variables unless it makes obvious good sense to do so.

By the way, I see this as totally unrelated to the issue of choosing good
names for variables and properly docuenting declarations.

Interesting that some programmer would be scornful of this (using the
word secretary, presumably NOT not in a complimentary sense). Sounds
like that is a programmer who I would NOT want working on my projects.
All programmers should be secretaries :-)

Re: [Q] To initialise or not.

[mjp]

"Thorsten Behrens" <thorsten.behrens@dorunth.hb.north.de> writes:

>I tend to give all my declarations some initial value (if possible) _and_
>an initial comment (giving a shorter or longer text about its usage and
>the background of this variable). In my eyes this saves me from having
>non-initialized variables (causing errors which are sometimes nasty to
>find) and it saves people reviewing my sources from wasting too much time
>to guess what I was thinking when "inventing" a variable (normally, I would
>not use a variable called 'X', but instead would have called it
>'Some_Meaningful_Name').

I think what to do depends on the strenght of your compiler.

Ideally, the hardware would have store both a value, and a
bit indicating whether the value was valid (initialised) or
not. If this hardware support is not provided, hopefully,
your compiler will do a dataflow analysis and flag "used but
not set" variables, even this can fail in things like loops or
assignments in conditionals.

I always prefer to force a detectable error so for instance I
would tend to initialise to an absurd value. E.g. for a
divisor variable, I would initialise to 0 in the declarations,
that way if it is used before set it will cause a divide by
zero exception. Of course not all operations will cause such
obvious errors and in other cases I would tend to use such an
out of bounds value that you would at least see the error in
the output and go looking for it.

The really insidious errors are the ones that don't look like
a problem, i.e. appear plausable.

Michael

--
On Australia is prohibited from redistributing this document in any way
Dr Michael Pilling                         Phone: +61 8 259 7017
DSTO ITD/SE 171 Labs                       Fax: +61 8 259 5589
PO Box 1500, Salisbury SA 5108, Australia  Michael.Pilling@dsto.defence.gov.au

Re: [Q] To initialise or not.

[Bob Gilbert]

In article <75602294@dorunth.hb.north.de>, "Thorsten Behrens" <thorsten.behrens@dorunth.hb.north.de> writes:
> Captain, bei Sternzeit Fri, 26 Apr 1996 18:55:28 GMT empfingen wir folgende
> Nachricht von Robert A Duff:
> 
> > In the above, I would *not* write "X: Integer := 0;".
> 
> This initialization would indeed make no sense. But in the example above
> (and in many similar cases) you could have used:
> 
>    declare
>      X :  INTEGER
>        := 12;
>        -- 'X' is initialized to 12 here because ...
>        -- It will be changed to '13' under the following circumstances ...
>        -- in the code piece following.
>    begin
>      if not ... then
>        X := 13;
>      end if;
>      ... -- some reads of 'X'

You could get fully carried away and do something like:

    function Init_X(Condition : BOOLEAN) return INTEGER is
      type VALUES_LIST is array (BOOLEAN) of INTEGER;
      Init_Values : constant VALUES_LIST := (False => 13, True => 12);
    begin
      return Init_Values(Condition);
    end Init_X;

    declare
      X : INTEGER := Init_X(<condition>);
    begin
      ...  -- some reads of 'X'

-Bob

Re: [Q] To initialise or not.

[Ken Garlington]

JP Thornley wrote:
> 
> However the issue of whether or not to require all scalar objects to be
> initialised has generated a substantial discussion without yet reaching
> a clear conclusion.  The Ada Quality and Style Guidelines are silent on
> this issue, so I would be interested in what other Ada users have found
> and what recommendations they would make.

Section 5.9.6 of the Ada 95 Quality and Style Guide does discuss initialization
issues. Some of the recommendations there are also applicable to Ada 83.

> (Note that some projects will be using Ada 83 for some time yet, so
> pragma Normalize_Scalars isn't an option).

Actually, Normalize_Scalars cannot be used to ensure that objects are
initialized before use; in fact, it definitely cannot be used to ensure
objects have _valid_ values before use!

Re: [Q] To initialise or not.

[Robert Dewar]

"Briefly, the argument for initialising everything is predictability of
operation (by avoiding a read of an uninitialised value).  The
argument against is that giving everything an initial value obscures the
fact that some objects *should* be initialised (and the initial value
has some significance) and other initialisations are there simply to
follow the rule (and the value has no particular significance)."

It is a shame to damage the readability and maintainability of code by
providing junk initializations. The desire for predictability is however
reasonable. There is no good solution in Ada 83. Really pragma
Normalize_Scalars is the only satsifactory answer here.