<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Wed, Mar 14, 2018 at 2:30 PM Hyman Rosen &lt;<a href="mailto:hyman.rosen@gmail.com" target="_blank">hyman.rosen@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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">&lt;<a href="mailto:Lawrence@crowl.org" target="_blank">Lawrence@crowl.org</a>&gt;</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 &quot;trust the programmer&quot; 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 &quot;trust the programmer to<br>
write correct programs&quot;.  If the programmer writes incorrect programs,<br>
it&#39;s on the programmer to deal with the consequences.<br></blockquote><div><br>No, that&#39;s wrong: &lt;<a href="http://beza1e1.tuxen.de/articles/spirit_of_c.html" target="_blank">http://beza1e1.tuxen.de/articles/spirit_of_c.html</a>&gt;<br>It really is just &quot;trust the programmer&quot;.<br></div></div></div></div></blockquote><div><br></div><div>The compiler is &quot;trusting the programmer&quot; the programmer to never run undefined behaviour. The language trusts the programmer in the sense that casts are not checked.</div><div><br></div><div>I don&#39;t see anything in your link <span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">that defends the interpretation of</span> &quot;trust the programmer&quot; as meaning that compiler should emit obvious assembly. Do you have a supplemental reference?</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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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&#39;s-complement<br>hardware, even when <font face="monospace, monospace">x</font> is <font face="monospace, monospace">INT_MIN</font>.<br></div></div></div></div></blockquote><div><br></div><div>There are a large number of reasons that a compiler should not emit the obvious operations on ordinary 2&#39;s complement hardware, as I have wide freedom to choose the contents of the &quot;...&quot;. It ranges from the very obvious (&quot;x = 0;&quot; so constant folding occurs and blocks emission of the negation, or &#39;x&#39; is never used again so dead code elimination blocks emission of the negation) to the less obvious (~x is used in multiple calculations in different expressions) to the downright hard to reason about.</div><div><br></div><div>The other reason to do something other than emit the &quot;obvious operations&quot; is to detect unintended overflow. F<span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">or one large industry example </span>Android security is deploying unsigned integer overflow checking: <a href="https://android-developers.googleblog.com/2016/05/hardening-media-stack.html" target="_blank">https://android-developers.googleblog.com/2016/05/hardening-media-stack.html</a> . Instead of overflow, their compiler emits an overflow check and trap instruction.</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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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 &quot;and your anchovy pizza will arrive tomorrow&quot;</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 &quot;issue the underlying machine instructions and return<br>whatever result they provide.&quot; Even if some platforms trap on overflow, that</div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>does not mean other platforms should have license to assume that overflow<br>never happens in valid programs.</div></div></div></div></blockquote><div><br></div><div><div style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">What semantics does &quot;issue the underlying machine instructions and return whatever result they provide&quot; have? What about template non-type arguments? Constant expression evaluation? Used in the size of an array?</div><div style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">What if the compiler uses &quot;whatever the machine does&quot; when determining the size of an array as part of compilation, then we copy the resulting program to a different computer that claims to have the same ISA, but where &quot;whatever that machine does&quot; happens to be different. (This situation would be surprising for integer arithmetic, but did occur for x86 floating point arithmetic.) Are you okay with the compiler evaluating one size for an array at compile time, but calculating a different size for the array at run time?</div><div style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">What if I tell you, for the sake of argument, that compilers today are already following your proposed rule: since you didn&#39;t specify which instructions to issue, you have no standing to complain about the instructions the compiler chose. Can you fix this without adding a listing of CPU instructions to the language standard and without fully defining it?</div></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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Indirecting a pointer should mean &quot;refer to<br>the memory pointed to as if there is an object there of the pointer type&quot; 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></div></div></div></div></blockquote><div><br></div><div>Suppose I have a function with two local variables, &quot;int x, y;&quot; and I take &amp;x, I can use x[1] (or x[-1]) to make changes to &#39;y&#39;?</div><div><br></div><div>And similarly, I can construct a pointer to stack variables <span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">in another call stack frame </span>whose address was never taken? As long as I can cast the right integer to a pointer?</div><div><br></div><div>Given these rules, when would it be valid to move automatic local variables into registers? Only when there are no opaque pointers used and no opaque functions called?</div><div><br></div><div>Nick</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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><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></div></div></blockquote><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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></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&#39;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>
_______________________________________________<br>
ub mailing list<br>
<a href="mailto:ub@isocpp.open-std.org" target="_blank">ub@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/ub" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/ub</a><br>
</blockquote></div></div>