[M3devel] [M3commit] CVS Update: cm3

[Tony Hosking]

Or, alternatively, we could turn it around and have a flag that turns off (for performance if desired) well-defined initialisations (much like nochecks does to turn off other runtime checks).  This would be in the spirit of the language spec, which says simply that some legal value is present, and simply go one step further in making the initialised value deterministic.  As far as I can tell, this changes only the behaviour of "automatic" variables (function-scope local variables) whose initial value can be any combination of bits in the variable.  All other variables get deterministic initial values already.

On 6 Jul 2010, at 13:04, Tony Hosking wrote:

> So, here is a proposal.
> Why not have a flag to the M3 compiler that tells it to initialise every value with zero for numbers, NIL for references, or FIRST(T) for enumerations/subranges?  I am sure we can come up with something reasonable for all the primitive types.
> This would be an aid to debugging, but avoid the need for explicit initialisation be expressed in the code.
> 
> Then, if you find yourself wondering if an uninitialised variable is the culprit for some bug then you can simply turn on the flag.
> It would also have the side-effect of passing the flag Jay is using to the cm3cg backend.
> 
> On 6 Jul 2010, at 13:02, hendrik at topoi.pooq.com wrote:
> 
>> On Tue, Jul 06, 2010 at 06:22:50AM +0000, Jay K wrote:
>>> 
>>> Programmers are notorious for making mistakes.
>>> 
>>> 
>>> When you write VAR a:INTEGER;
>>> you make the human proofreading your code have to work much harder
>>> to do the data/control flow analysis to make sure you didn't
>>> use the uninitialized value.
>>> 
>>> 
>>> Using the a := 0 value might still be "wrong", but is it at least consistent
>>> and the penalty for getting it wrong is generally less severe.
>>> 
>>> Now, I don't want there to be a bug either way, but I feel that a consistent 0 is much "safer"
>>> than uninitialized. Either is typesafe, sure, but type safe is just the bare minimum expectation
>>> for my code. It must not only be type safe, but act correctly.
>>> 
>>> Again, compiler isn't generally a program proofer, but the little it can do, let it do.
>> 
>> Agree with letting the compiler find flaws by flow analysis and 
>> report them, if it can.
>> 
>> But explicitly initializing it so zero so that (a) the ocmpiler won't 
>> notice it's really uninitilized, and (b) it's going to have less of a 
>> penalty for getting it wrong?  I disagree with this.  If there's a bug 
>> in my program I want to find it so I can fix it.  I don't want it 
>> masked by an arbitrary but innocuous initial value.
>> 
>> Here's where letting the ocmpiler initialize undefined integer 
>> variables to something like 1683002888 might actually contribute to 
>> debugging, especially if it chooses this consistently so you can rerun 
>> the program reliable while you close in on the error.
>> 
>> But for the programmer to write
>> 
>> VAR x := 1683002888;
>> 
>> would likely confuse the human reader, who would spend ages pondering 
>> why *that* value.
>> 
>> - hendrik
>