Re: Uninitialized variables

From: *** Hendrickson (***.hendrickson_at_att.net)
Date: 04/07/04 

Date: Wed, 07 Apr 2004 18:38:40 GMT

Pterostyrax wrote:

> In a discussion on whether or not to allow a compiler switch to set
> unintialized variables to zero on the old CVF forum, I also suggested
> rather than just random initialization as was currently being done,
> that it would be nice if you could initialize all reals and integers
> to the largest number that could be represented on the machine. Then,
> in a very large number of cases, a runtime error could be generated
> when an overflow/underflow occurred, thus taking one to the
> uninitialized variable. It appears that CVF did just this as it now
> eems reals and integers have a default initialization of the largest
> real/integer for the precision compiled for.
>
> Does anyone else think that this might be a good idea for possible
> incorporation into the standard? If not, how about "strong
> encouragement" for compiler developers? It sure seems like it would
> be easy to implement and would at least start to approach Lahey's and
> Salford's runtime error checking for uninitialized variables. Or am I
> full of it again?

I think it is a great idea and all compilers should do
something like that by default. BUT, it's not a thing
that can be standardized. There's no "good" reason for
that, but several practical problems. In no particular
order:
1) The Fortran compiler no longer "owns" the linker/OS
     and can't always force this to happen.
2) Many implementations allow COMMON to be partially
     initialized in different routines and, coupled with
     things like DLLs, it can be difficult or impossible
     to sort things out.
3) It's worse for blank common, which is often special
     cased (and abused) and doesn't necessarily have a
     well defined length (at least in old codes).
4) Most compilers now implement local variables on a
     stack, so the initialization would become a run-time
     thing and many vendors/users are reluctant to waste a
     couple of cycles per variable merely to avoid a wrong
     answer ;-) .
5) Same problem for allocatable things, should the allocate
     routine slow down to do this?
6) It's not guaranteed to work, especially for integer
     variables, all of the time and the standard doesn't
     generally require behaviour that can't be well defined.
7) The standard generally describes how things it describes
     should work (yes, that's circular) but doesn't describe
     how things shouldn't work. That allows vendors to try
     new things, and for good or bad, some vendors thought
     [think] spraying memory with zero was a good thing. The
     standardizing process tends not to do things that cause
     common extensions to become non-standard.
8) In about a million different places the standard says
     you can't use a variable before you initialize it; it
     would be editorially hard to change that and try to say
     what [usually should] happen if you do.

None of those are mathematical proofs that it shouldn't
be done, merely my guesses at some expected problems if
people try. Strong encouragement is a great idea and
everybody should yell at their favorite vendors.

*** Hendrickson