Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.arch
Subject: Re: Parity hardware for uninitialized variable checking?
Message-ID: <28784@news.Think.COM>
Date: 3 Sep 89 18:12:07 GMT
References: <12.filbo@gorn.santa-cruz.ca.us> <4322@druhi.ATT.COM> <14166@polyslo.CalPoly.EDU>
Sender: news@Think.COM
Distribution: usa
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 29

In article <14166@polyslo.CalPoly.EDU> ttwang@polyslo.CalPoly.EDU (Thomas Wang) writes:
>The problems you mentioned are the problem of the particular languages.
>The hardware should not be be doing error detection which the software should
>be handling in the first place.

Runtime error detection slows down programs when done only in
software.  That's why language designers would like hardware
facilities to support it.

>The fact that you can use a variable before initializing it shows the flaw
>in the language design.  Every variables should be initialized.  The C++
>language is a modern language which you can have a high confidence that
>all variables are initialized.
>If you take the object-oriented view, allowing the creation of an object
>with undefined initial state is an obvious error.

Just because a variable is initialized doesn't mean it has a *useful*
value.  C automatically initializes all statics to 0, but that might
not be a valid value as far as the application is concerned.

>Yes.  Insist you initialize a variable when you create it.

What if you don't know what value it should have yet?

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar