[M3commit] CVS Update: cm3

Jay K jay.krell at cornell.edu
Tue Jul 6 00:59:37 CEST 2010


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