
<html><head><base href="x-msg://2193/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Sigh...<div><br></div><div>You are tilting at windmills.<div><br>

<br><div><div>On 5 Jul 2010, at 22:45, Jay K wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div class="hmmessage" style="font-size: 10pt; font-family: Tahoma; ">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.<span class="Apple-converted-space"> </span><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:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> Date: Mon, 5 Jul 2010 22:36:29 -0400<br>> To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3commit@elegosoft.com">m3commit@elegosoft.com</a><br>> Subject: Re: [M3commit] CVS Update: cm3<br>><span class="Apple-converted-space"> </span><br>> But the compiler frontend has already proved the variable has a valid initial value.<span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> Sent from my iPhone<br>><span class="Apple-converted-space"> </span><br>> On Jul 5, 2010, at 6:59 PM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<br>><span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><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>> ><span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> > - Jay<br>> ><span class="Apple-converted-space"> </span><br>> > ----------------------------------------<br>> >> Subject: Re: [M3commit] CVS Update: cm3<br>> >> From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >> Date: Mon, 5 Jul 2010 18:44:16 -0400<br>> >> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3commit@elegosoft.com">m3commit@elegosoft.com</a><br>> >> To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >><span class="Apple-converted-space"> </span><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>> >><span class="Apple-converted-space"> </span><br>> >> You are seeing Modula-3 through C spectacles, where so much of the language is undefined.<br>> >><span class="Apple-converted-space"> </span><br>> >> On 5 Jul 2010, at 17:51, Jay K wrote:<br>> >><span class="Apple-converted-space"> </span><br>> >>><span class="Apple-converted-space"> </span><br>> >>> As a human reading code (very finite cycles), I don't like to see:<br>> >>><span class="Apple-converted-space"> </span><br>> >>><span class="Apple-converted-space"> </span><br>> >>> VAR a: type;<br>> >>> BEGIN<br>> >>> ...<br>> >>> END<br>> >>><span class="Apple-converted-space"> </span><br>> >>><span class="Apple-converted-space"> </span><br>> >>> no matter the contents of "...".<br>> >>><span class="Apple-converted-space"> </span><br>> >>><span class="Apple-converted-space"> </span><br>> >>> I'd much rather see:<br>> >>><span class="Apple-converted-space"> </span><br>> >>><span class="Apple-converted-space"> </span><br>> >>> VAR a: type := 0;<br>> >>><span class="Apple-converted-space"> </span><br>> >>><span class="Apple-converted-space"> </span><br>> >>><span class="Apple-converted-space"> </span><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>> >>><span class="Apple-converted-space"> </span><br>> >>><span class="Apple-converted-space"> </span><br>> >>> I just don't think it is worth the risk.<br>> >>><span class="Apple-converted-space"> </span><br>> >>><span class="Apple-converted-space"> </span><br>> >>> - Jay<br>> >>><span class="Apple-converted-space"> </span><br>> >>><span class="Apple-converted-space"> </span><br>> >>><span class="Apple-converted-space"> </span><br>> >>> ----------------------------------------<br>> >>>> Subject: Re: [M3commit] CVS Update: cm3<br>> >>>> From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >>>> Date: Mon, 5 Jul 2010 17:34:51 -0400<br>> >>>> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3commit@elegosoft.com">m3commit@elegosoft.com</a><br>> >>>> To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >>>><span class="Apple-converted-space"> </span><br>> >>>> Huh?<br>> >>>><span class="Apple-converted-space"> </span><br>> >>>> On 5 Jul 2010, at 17:15, Jay K wrote:<br>> >>>><span class="Apple-converted-space"> </span><br>> >>>>><span class="Apple-converted-space"> </span><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>> >>>>><span class="Apple-converted-space"> </span><br>> >>>>> That is, the compiler guarantees are from sufficient relative to correctness.<br>> >>>>><span class="Apple-converted-space"> </span><br>> >>>>> - Jay<br>> >>>>><span class="Apple-converted-space"> </span><br>> >>>>> ----------------------------------------<br>> >>>>>> From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >>>>>> Date: Mon, 5 Jul 2010 16:50:00 -0400<br>> >>>>>> To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >>>>>> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3commit@elegosoft.com">m3commit@elegosoft.com</a><br>> >>>>>> Subject: Re: [M3commit] CVS Update: cm3<br>> >>>>>><span class="Apple-converted-space"> </span><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>> >>>>>><span class="Apple-converted-space"> </span><br>> >>>>>> On 5 Jul 2010, at 16:45, Jay K wrote:<br>> >>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>><span class="Apple-converted-space"> </span><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>> >>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>> - Jay<br>> >>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>> ----------------------------------------<br>> >>>>>>>> From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >>>>>>>> Date: Mon, 5 Jul 2010 14:31:01 -0400<br>> >>>>>>>> To:<span class="Apple-converted-space"> </span><a href="mailto:jkrell@elego.de">jkrell@elego.de</a><br>> >>>>>>>> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3commit@elegosoft.com">m3commit@elegosoft.com</a><br>> >>>>>>>> Subject: Re: [M3commit] CVS Update: cm3<br>> >>>>>>>><span class="Apple-converted-space"> </span><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>> >>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>> On 5 Jul 2010, at 15:22, Jay Krell wrote:<br>> >>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> CVSROOT: /usr/cvs<br>> >>>>>>>>> Changes by: jkrell@birch. 10/07/05 15:22:28<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> Modified files:<br>> >>>>>>>>> cm3/m3-tools/cvsup/suplib/src/text_cm3/: SupMiscText.m3<br>> >>>>>>>>><span class="Apple-converted-space"> </span><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>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> because raising an exception isn't currently "noreturn"<br>> >>>>>>>>> so initialize it to 0<br>> >>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>><span class="Apple-converted-space"> </span><br>> >>>>><span class="Apple-converted-space"> </span><br>> >>>><span class="Apple-converted-space"> </span><br>> >>><span class="Apple-converted-space"> </span><br>> >><span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br></div></span></blockquote></div><br></div></div></body></html>