<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 14, 2018 at 3:44 PM, Lawrence Crowl <span dir="ltr"><<a href="mailto:Lawrence@crowl.org" target="_blank">Lawrence@crowl.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The phrase "trust the programmer" was directed to language designers<br>
and compiler writers to not be nit-picking or straight-jacketing the<br>
program. The long form of the phrase is "trust the programmer to<br>
write correct programs". If the programmer writes incorrect programs,<br>
it's on the programmer to deal with the consequences.<br></blockquote><div><br>No, that's wrong: <<a href="http://beza1e1.tuxen.de/articles/spirit_of_c.html">http://beza1e1.tuxen.de/articles/spirit_of_c.html</a>><br>It really is just "trust the programmer".<br><br>As far as incorrect programs, such programs were deliberately designated<br>as incorrect so that the optimizationists could break them. There is no<br>reason why a program that says <font face="monospace, monospace">int x; ... x = ~x + 1;</font> should do<br>anything besides the obvious operations on ordinary 2's-complement<br>hardware, even when <font face="monospace, monospace">x</font> is <font face="monospace, monospace">INT_MIN</font>.<br><br>It is discouraging, looking at the linked C 2003 Rationale, how most of the<br>principles listed in the introduction are blithely violated by the C (and C++)<br>standards, with absolutely no sense of irony or self-awareness:<br><ul><li>Existing code is important, existing implementations are not.<br></li><li>C code can be non-portable.<br></li><li>Avoid “quiet changes.”<br></li><li>A standard is a treaty between implementor and programmer.<br></li><li>Trust the programmer.<br></li><li>Don’t prevent the programmer from doing what needs to be done.</li></ul></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Undefined behavior has meant "and your anchovy pizza will arrive tomorrow"</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">for decades. Partly the meaning is there because once a pointer goes haywire,</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">anything can happen.<br></blockquote><div><br>Then the error lies in characterizing certain behavior as undefined, when it<br>should instead be unspecified or implementation-dependent. Signed integer<br>arithmetic should mean "issue the underlying machine instructions and return<br>whatever result they provide." Even if some platforms trap on overflow, that<br>does not mean other platforms should have license to assume that overflow<br>never happens in valid programs. Indirecting a pointer should mean "refer to<br>the memory pointed to as if there is an object there of the pointer type" and<br>should be undefined only if the pointer does not point to correctly aligned<br>memory owned by the (entire) program. And so on.<br><br><b>No behavior should ever be designated undefined in order to allow<br>optimizers to generate code by assuming that the behavior never occurs.</b></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
And BTW, the development and implementation of Ada costs way more than<br>
most contemporary organizations could have spent. In particular, a<br>
small research team at Bell Labs did not have that budget.<br></blockquote><div><br>What does that have to do with anything? Jean Ichbiah's design of Ada<br>was a work of genius, and it was done on paper. The free GNAT Ada<br>compiler, part of GCC, was developed along with the Ada95 standard<br>revision.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">That does not, however, change the fact that the code has always been wrong.</blockquote><div><br>You may believe that, but I believe you are wrong. </div></div></div></div>