[Oberon] Obstacles when programming in RISC Oberon and proposed patches

[Michael Schierl]

Am 25.05.2014 13:34, schrieb Richard Hable:
>> 1. Uninitialized local variables
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> When something is allocated on the heap with NEW, all bytes are zeroed
>> out (in Kernel.New). Variables declared at the top of the module are
>> also zeroed out (in Modules.Load). Only local variables that live on the
>> stack are not zeroed out, but stay what they are. It is easy to miss an
>> initialization, resulting in a program that "sometimes works". On the
>> other hand, it is also easy to patch the compiler to zero out these
>> stack areas:
> 
> But this would lead to inefficiency and incompatible Oberon programs 
> relying on automatic initialization of local variables.

Yes, true. One could recompile again with initialization with all ones
and test if it still works, to reduce this "risk". I also thought about
having a "debug mode" tracking every variable word (local or not) using
a shadow bitfield, and having the code set the bit if the variable is
"uninitialized" (after new or when stack is enlarged) and TRAPping when
the program reads unitinialized memory, but the memory overhead and
inefficiency is even worse there (at least for debug mode); and since
the inefficiency/incompatibility is already there for Kernel.New() I
thought it would not be that bad to add it for locals, too.

> I would prefer a solution similar to Java, where the compiler does not 
> allow reading local variables, if it isn't sure that they have already 
> been assigned a value. The Oberon compiler could create warnings in 
> such cases.

Of course that would be the best solution. Unfortunately, unlike Java,
Oberon has VAR parameters, which do not really work well with this
static checking, unless the initialization state of the variable is part
of the declaration (like it is with C#, where you have "out" parameters
for variables initially potentially uninitialized that have to be
initialized on every code path, and "var" parameters for variables
initially initialized). Therefore, this would add complexity to the
language specification as well. And I am unsure if this complexity is
compatible with Wirth's minimalistic approach.

And I don't believe in warnings - I don't like the mess around warnings
in the C programming language. Either you find a solution that creates
zero false positives and create errors (not warnings), or don't do it at
all.


Regards,


Michael