[M3commit] CVS Update: cm3

Jay K jay.krell at cornell.edu
Wed Jun 2 02:10:02 CEST 2010


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.
 
 
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.
 
 
 
(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
> 		 	   		  


More information about the M3commit mailing list