<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
We are going in circles.<BR>
<BR>
<BR>
You have a lower bar for the level of correctness you would like the compiler to try to help the programmer to attain.<BR>
"valid" doesn't mean much sometimes, given that any value is "valid".<BR>
<BR>
Knowingly letting uninitialized data creep in is not good.<BR>
You can't always help it, and you can't analyze away all bugs, but some you can.<BR>
<BR>
<BR>
Perhaps I don't realize the extent that Modula-3's safety guarantee restrict what can happen when an uninitialized variable gets used.<BR>
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.<BR>
<BR>
I will try making the exception raising be noreturn and maybe we can then analyze away the use of uninitialized data.<BR>
But really I think these are not changes.<BR>
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.<BR>
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. <BR>
<BR>
<BR>
Some large fraction of the time the compiler will optimize away such initialization anyway.<BR>
Other fraction, the performance difference will not be noticable.<BR>
And maybe some small fraction of the time it will be a noticable slow down, maybe.<BR>
<BR>
<BR>
- Jay<BR> <BR>
> From: hosking@cs.purdue.edu<BR>> Date: Mon, 5 Jul 2010 22:36:29 -0400<BR>> To: jay.krell@cornell.edu<BR>> CC: m3commit@elegosoft.com<BR>> Subject: Re: [M3commit] CVS Update: cm3<BR>> <BR>> But the compiler frontend has already proved the variable has a valid initial value. <BR>> <BR>> Sent from my iPhone<BR>> <BR>> On Jul 5, 2010, at 6:59 PM, Jay K <jay.krell@cornell.edu> wrote:<BR>> <BR>> > <BR>> > There will *always* be bugs, in every program. Even in the CPU (really, I've seen it, some are easy to run afoul of.)<BR>> > As I said, the compiler cannot be a "general program proofer". Since that is impossible, cannot exist.<BR>> > But we can take some small easy steps to find some of them early.<BR>> > We do type checking after all. Should we not bother with that?<BR>> > 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.<BR>> > Just because we can't be perfect, doesn't mean we shouldn't do what is at least "easy".<BR>> > <BR>> > <BR>> > - Jay<BR>> > <BR>> > ----------------------------------------<BR>> >> Subject: Re: [M3commit] CVS Update: cm3<BR>> >> From: hosking@cs.purdue.edu<BR>> >> Date: Mon, 5 Jul 2010 18:44:16 -0400<BR>> >> CC: m3commit@elegosoft.com<BR>> >> To: jay.krell@cornell.edu<BR>> >> <BR>> >> 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.<BR>> >> <BR>> >> You are seeing Modula-3 through C spectacles, where so much of the language is undefined.<BR>> >> <BR>> >> On 5 Jul 2010, at 17:51, Jay K wrote:<BR>> >> <BR>> >>> <BR>> >>> As a human reading code (very finite cycles), I don't like to see:<BR>> >>> <BR>> >>> <BR>> >>> VAR a: type;<BR>> >>> BEGIN<BR>> >>> ...<BR>> >>> END<BR>> >>> <BR>> >>> <BR>> >>> no matter the contents of "...".<BR>> >>> <BR>> >>> <BR>> >>> I'd much rather see:<BR>> >>> <BR>> >>> <BR>> >>> VAR a: type := 0;<BR>> >>> <BR>> >>> <BR>> >>> <BR>> >>> and know very quickly and without a doubt that a is never used uninitialized.<BR>> >>> I've been bitten too much by microoptimizations around not initializing locals.<BR>> >>> Some large fraction of the time the compiler will optimize away the initialization.<BR>> >>> (ie. depending on the contents of "...")<BR>> >>> Some other large fraction of the time the performance difference will be unmeasurable.<BR>> >>> So much code is I/O bound already, let alone compute bound by more significant "algorithmic" factors.<BR>> >>> And then some small fraction of the time, maybe, it will be a bad pessimization.<BR>> >>> <BR>> >>> <BR>> >>> I just don't think it is worth the risk.<BR>> >>> <BR>> >>> <BR>> >>> - Jay<BR>> >>> <BR>> >>> <BR>> >>> <BR>> >>> ----------------------------------------<BR>> >>>> Subject: Re: [M3commit] CVS Update: cm3<BR>> >>>> From: hosking@cs.purdue.edu<BR>> >>>> Date: Mon, 5 Jul 2010 17:34:51 -0400<BR>> >>>> CC: m3commit@elegosoft.com<BR>> >>>> To: jay.krell@cornell.edu<BR>> >>>> <BR>> >>>> Huh?<BR>> >>>> <BR>> >>>> On 5 Jul 2010, at 17:15, Jay K wrote:<BR>> >>>> <BR>> >>>>> <BR>> >>>>> 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.<BR>> >>>>> Type safe is just a minimum bar, one that should always be exceeded, even if the compiler is completely unable to validate it.<BR>> >>>>> <BR>> >>>>> That is, the compiler guarantees are from sufficient relative to correctness.<BR>> >>>>> <BR>> >>>>> - Jay<BR>> >>>>> <BR>> >>>>> ----------------------------------------<BR>> >>>>>> From: hosking@cs.purdue.edu<BR>> >>>>>> Date: Mon, 5 Jul 2010 16:50:00 -0400<BR>> >>>>>> To: jay.krell@cornell.edu<BR>> >>>>>> CC: m3commit@elegosoft.com<BR>> >>>>>> Subject: Re: [M3commit] CVS Update: cm3<BR>> >>>>>> <BR>> >>>>>> 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.<BR>> >>>>>> <BR>> >>>>>> On 5 Jul 2010, at 16:45, Jay K wrote:<BR>> >>>>>> <BR>> >>>>>>> <BR>> >>>>>>> I will maybe see about doing better here.<BR>> >>>>>>> Initializing locals doesn't seem like such a bad change though.<BR>> >>>>>>> I like the code to be "obviously correct" by a quick read by a human.<BR>> >>>>>>> <BR>> >>>>>>> - Jay<BR>> >>>>>>> <BR>> >>>>>>> ----------------------------------------<BR>> >>>>>>>> From: hosking@cs.purdue.edu<BR>> >>>>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400<BR>> >>>>>>>> To: jkrell@elego.de<BR>> >>>>>>>> CC: m3commit@elegosoft.com<BR>> >>>>>>>> Subject: Re: [M3commit] CVS Update: cm3<BR>> >>>>>>>> <BR>> >>>>>>>> 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.<BR>> >>>>>>>> <BR>> >>>>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote:<BR>> >>>>>>>> <BR>> >>>>>>>>> CVSROOT: /usr/cvs<BR>> >>>>>>>>> Changes by: jkrell@birch. 10/07/05 15:22:28<BR>> >>>>>>>>> <BR>> >>>>>>>>> Modified files:<BR>> >>>>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3<BR>> >>>>>>>>> <BR>> >>>>>>>>> Log message:<BR>> >>>>>>>>> ../src/text_cm3/SupMiscText.m3: In function 'SupMisc__DecodeWS':<BR>> >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: warning: 'M3_Bkn9rd_ch' may be used uninitialized in this function<BR>> >>>>>>>>> ../src/text_cm3/SupMiscText.m3:211: note: 'M3_Bkn9rd_ch' was declared here<BR>> >>>>>>>>> <BR>> >>>>>>>>> because raising an exception isn't currently "noreturn"<BR>> >>>>>>>>> so initialize it to 0<BR>> >>>>>>>> <BR>> >>>>>>> <BR>> >>>>>> <BR>> >>>>> <BR>> >>>> <BR>> >>> <BR>> >> <BR>> > <BR> </body>
</html>