[M3commit] CVS Update: cm3

Tue Jul 6 04:45:23 CEST 2010

We are going in circles.

You have a lower bar for the level of correctness you would like the compiler to try to help the programmer to attain.
"valid" doesn't mean much sometimes, given that any value is "valid".

Knowingly letting uninitialized data creep in is not good.
You can't always help it, and you can't analyze away all bugs, but some you can.

Perhaps I don't realize the extent that Modula-3's safety guarantee restrict what can happen when an uninitialized variable gets used.
But, really? I mean, let's say it ends up as an array index. It might be "small and valid", and arbitrary data will be operated on, or "large an invalid" and you'll get a nice exception upon indexing. The second case is ok but the first is pretty bad. I understand zero is similar to "small and valid and wrong" but at least it is consistent, repeatable, and perhaps more likely to be found therefore.

I will try making the exception raising be noreturn and maybe we can then analyze away the use of uninitialized data.
But really I think these are not changes.
Even if the compiler can tell the data is used uninitialized, as a programmer, maybe I don't trust the compiler's analysis there -- for example the NT386 backend doesn't do the analysis, nor does gcc when not optimizing.
As a programmer I want code to be as clear and clearly correct as possible. Throwing in "unnecesssary" initialization is an easy cheap step there I think. 

Some large fraction of the time the compiler will optimize away such initialization anyway.
Other fraction, the performance difference will not be noticable.
And maybe some small fraction of the time it will be a noticable slow down, maybe.

 - Jay

> From: hosking at cs.purdue.edu
> Date: Mon, 5 Jul 2010 22:36:29 -0400
> To: jay.krell at cornell.edu
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> 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
> >>>>>>>> 
> >>>>>>> 
> >>>>>> 
> >>>>> 
> >>>> 
> >>> 
> >> 
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100706/9e502029/attachment-0002.html>