[M3commit] CVS Update: cm3

Tony Hosking hosking at cs.purdue.edu
Tue Jul 6 05:15:14 CEST 2010 

Sigh...

You are tilting at windmills.


On 5 Jul 2010, at 22:45, Jay K wrote:

> 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/20100705/52043baf/attachment-0002.html>

More information about the M3commit mailing list