[M3commit] CVS Update: cm3

Tony Hosking hosking at cs.purdue.edu
Tue Jul 6 04:36:29 CEST 2010


But the compiler frontend has already proved the variable has a valid initial value. 

Sent from my iPhone

On Jul 5, 2010, at 6:59 PM, Jay K <jay.krell at cornell.edu> wrote:

> 
> There will *always* be bugs, in every program. Even in the CPU (really, I've seen it, some are easy to run afoul of.)
>   As I said, the compiler cannot be a "general program proofer". Since that is impossible, cannot exist.
> But we can take some small easy steps to find some of them early.
> We do type checking after all. Should we not bother with that?
> Some simple data/control flow analysis is some of the steps to take beyond that and all compilers do it, both to optimize and to find bugs.
>  Just because we can't be perfect, doesn't mean we shouldn't do what is at least "easy".
> 
> 
>  - Jay
> 
> ----------------------------------------
>> Subject: Re: [M3commit] CVS Update: cm3
>> From: hosking at cs.purdue.edu
>> Date: Mon, 5 Jul 2010 18:44:16 -0400
>> CC: m3commit at elegosoft.com
>> To: jay.krell at cornell.edu
>> 
>> That is you view, but at odds with why Modula-3 was designed the way it was. I think we've already had this conversation before. The point is that even when a variable is initialised to 0 as you prefer there may still be bugs in the program.
>> 
>> You are seeing Modula-3 through C spectacles, where so much of the language is undefined.
>> 
>> On 5 Jul 2010, at 17:51, Jay K wrote:
>> 
>>> 
>>> As a human reading code (very finite cycles), I don't like to see:
>>> 
>>> 
>>> VAR a: type;
>>> BEGIN
>>> ...
>>> END
>>> 
>>> 
>>> no matter the contents of "...".
>>> 
>>> 
>>> I'd much rather see:
>>> 
>>> 
>>> VAR a: type := 0;
>>> 
>>> 
>>> 
>>> and know very quickly and without a doubt that a is never used uninitialized.
>>> I've been bitten too much by microoptimizations around not initializing locals.
>>> Some large fraction of the time the compiler will optimize away the initialization.
>>> (ie. depending on the contents of "...")
>>> Some other large fraction of the time the performance difference will be unmeasurable.
>>> So much code is I/O bound already, let alone compute bound by more significant "algorithmic" factors.
>>> And then some small fraction of the time, maybe, it will be a bad pessimization.
>>> 
>>> 
>>> I just don't think it is worth the risk.
>>> 
>>> 
>>> - Jay
>>> 
>>> 
>>> 
>>> ----------------------------------------
>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>> From: hosking at cs.purdue.edu
>>>> Date: Mon, 5 Jul 2010 17:34:51 -0400
>>>> CC: m3commit at elegosoft.com
>>>> To: jay.krell at cornell.edu
>>>> 
>>>> Huh?
>>>> 
>>>> On 5 Jul 2010, at 17:15, Jay K wrote:
>>>> 
>>>>> 
>>>>> At least some of these were Word.T. "valid" is still "random" and the code is unpredictable, at least by a quick read, even if type safe.
>>>>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it.
>>>>> 
>>>>> That is, the compiler guarantees are from sufficient relative to correctness.
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Mon, 5 Jul 2010 16:50:00 -0400
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3commit at elegosoft.com
>>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>> 
>>>>>> But we've been this route before. Modula-3 ensures every variable is initialised with a valid value. I don't see how your adding an initialiser makes it more obviously correct.
>>>>>> 
>>>>>> On 5 Jul 2010, at 16:45, Jay K wrote:
>>>>>> 
>>>>>>> 
>>>>>>> I will maybe see about doing better here.
>>>>>>> Initializing locals doesn't seem like such a bad change though.
>>>>>>> I like the code to be "obviously correct" by a quick read by a human.
>>>>>>> 
>>>>>>> - Jay
>>>>>>> 
>>>>>>> ----------------------------------------
>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400
>>>>>>>> To: jkrell at elego.de
>>>>>>>> CC: m3commit at elegosoft.com
>>>>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>>>> 
>>>>>>>> Jay, I am perplexed that we are adding things to Modula-3 source because of compiler backend brokenness just to avoid back-end warnings. Better to fix the backend so that RAISE is noreturn. This should not be difficult to do.
>>>>>>>> 
>>>>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote:
>>>>>>>> 
>>>>>>>>> CVSROOT: /usr/cvs
>>>>>>>>> Changes by: jkrell at birch. 10/07/05 15:22:28
>>>>>>>>> 
>>>>>>>>> Modified files:
>>>>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3
>>>>>>>>> 
>>>>>>>>> Log message:
>>>>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS':
>>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function
>>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here
>>>>>>>>> 
>>>>>>>>> because raising an exception isn't currently "noreturn"
>>>>>>>>> so initialize it to 0
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>                         



More information about the M3commit mailing list