Initialization

[stachour@sctc.com (Paul Stachour)]

ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:

>I would rather see features that help people detect or avoid the error
>of using an uninitialised variable rather than features which define
>the problem away.  For example, if arrays with fill pointers were a
>standard part of the language (perhaps defined as a standard package),
>then we'd be close enough to Dijkstra's arrays to get some of the
>protection without being too far from the kind of array already present.

>Don't expect default initial values for types to be an unmixed blessing.

As one who has programmed regularly in more than an half-dozen languages,
and has worked on teams that have implemented 3 compilers for different
lanauges, I agree.

If you have a variable that is unitialized, then a good flow anyalysis
tool (we had some inside one of the compilers) can follow your
control-flow and give you "used before set" messages.  When you do
have something initialized, it is, by definition, set.  Thus the
flow-analysis gives you nothing.

I long for the (ancient) FORTRAN II compiler I used on an IBM 7074
in the mid-1960s.  It set all of the words in the machine to an
"invalid pattern" before beginning your program.  And then if you
fetched anything that hadn't been set, you took a hardware fault and
the run-time told what you were doing wrong.

Much like Saber-C and other good c-interpreters can do today,
but with hardware support.

One problem is when you have an uninitialized item as a component
of a struacture and you assign one instance of the structre to another.
Do you get a fault or not.  You really aren't "using" the item yet.

Enjoy. ...Paul
-- 
Paul Stachour          SCTC, 1210 W. County Rd E, Suite 100           
stachour@sctc.com          Arden Hills, MN  55112
                             [1]-(612) 482-7467