[M3commit] CVS Update: cm3

[Tony Hosking]

C provides no guarantees about initialisation.

Modula-3 requires that all variables be initialised (explicitly or by the compiler) as necessary to ensure they have a valid value for their type.

So, basically, the warning you are getting from the gcc backend is not pertinent to Modula-3.

On 1 Jun 2010, at 20:10, Jay K wrote:

> 
> ok, so in C:
> 
> int F()
> {
>  int i;
>  return i;
> }
> 
> should warn or not?
> Prevailing wisdom is definitely.
> Main known exception is code to generate random numbers.
>  I believe this is how Debian broke key generation.
> 
> 
> Modula-3:
> 
> 
> PROCEDURE F(): INTEGER = 
> VAR i: INTEGER;
> BEGIN
>  RETURN i;
> END F;
> 
> 
> Should warn or not?
> Since this identical to the C, prevailing wisdom is definitely.

No, because Modula-3 guarantees the value of i is valid for the type.  It could be a random value of bits in this case because all bit combinations are valid for a Modula-3 INTEGER.  If you tried something like a subrange [0..3] then you will see explicit initialisation with a value in the range [0..3].

> They are, I guess, "safe", but most likely, incorrect.
> 
> 
> The compiler may have made "safety" guarantees, and they are significant,
> but safe is far from correct, and however smart the compiler can be to look for correctness issues, is also nice.

You are living in C land.

> (Friend of mine conjectured something like: Safety guarantees have people deluded. Software will still have plenty of bugs and be plenty difficult to get correct and require plenty of testing. Safety guarantees help, but they are only a small step toward actual correctness.)
> 
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> Subject: Re: [M3commit] CVS Update: cm3
>> From: hosking at cs.purdue.edu
>> Date: Tue, 1 Jun 2010 20:04:00 -0400
>> CC: jkrell at elego.de; m3commit at elegosoft.com
>> To: jay.krell at cornell.edu
>> 
>> Sure, an INTEGER is a valid value whatever the bits.
>> 
>> 
>> On 1 Jun 2010, at 17:44, Jay K wrote:
>> 
>>> 
>>> Start removing the rampant use of volatile in the backend and these warnings show up.
>>> 
>>> Volatile quashes the uninitialized checks in the backend.
>>> 
>>> Is it really ok for an INTEGER to be uninitialized? I realize it contains an "integer" value, as all bit patterns are.
>>> 
>>> Some of these really do seem like bugs. Some do not.
>>> I'll try making fault_proc noreturn, which should remove some of them.
>>> 
>>> 
>>> - Jay
>>> 
>>> 
>>> 
>>> 
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> To: jkrell at elego.de
>>>> Date: Tue, 1 Jun 2010 16:29:20 -0500
>>>> CC: m3commit at elegosoft.com
>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>> 
>>>> This is bogus. The M3 compiler guarantees all variables are initialized.
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>> On Jun 1, 2010, at 2:42 PM, jkrell at elego.de (Jay Krell) wrote:
>>>> 
>>>>> CVSROOT: /usr/cvs
>>>>> Changes by: jkrell at birch. 10/06/01 14:42:00
>>>>> 
>>>>> Modified files:
>>>>> cm3/m3-libs/m3core/src/convert/: Convert.m3
>>>>> 
>>>>> Log message:
>>>>> initialize locals; I get warnings that some not quite all, are
>>>>> used uninitialized if I remove the volatile/sideeffects on every
>>>>> load/store in parse.c
>>