<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Aug 4, 2017 at 9:34 AM Peter Lawrence <<a href="mailto:peterl95124@sbcglobal.net">peterl95124@sbcglobal.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Daniel,<div> I think you do or at least did work at Apple,</div><div>which is highly invested in static analyzers, in fact</div><div>one of the reasons they chose to use LLVM is because</div><div>of its suitability as a base for static analyzers. I am</div><div>guessing that the standard software engineering practice</div><div>at Apple is that software needs to be compiler warning free,</div><div>static analyzer warning free, and dynamic sanitizer warning</div><div>free. Given all that, then there really isn’t anything left for</div><div>the compiler to delete when it comes to deleting “UB”.</div></div></blockquote><div><br>That's, again, not exactly true - examples have been given on several of these threads where a perfectly valid (& warning, static, and dynamic analysis clean) program contains dead UB that can be deleted. That's partly the point of building those tools (static, dynamic, etc), to make sure these optimizations (deleting UB code as dead, for example) can be made safely (& when a user stumbles over problems, they can use the tools to double check/get a better message about where they went wrong).<br><br>As in the example I gave previously.<br><br> bool is_good_for_thing(int*);<br> void first_thing();<br> void middle_thing(int);<br> void last_thing();<br><br> void do_all_the_things(int *i) {<br> first_thing();<br> if (is_good_for_thing(i))<br> middle_thing(*i);<br> last_thing();<br> }<br> <br> void do_all_default_things() {<br> do_all_the_things(nullptr);<br> }<br><br> // in another file:<br> bool is_good_for_things(int* i) {<br> if (!i)<br> return false;<br> /* lots of other tests of *i for 'goodness' */<br> }<br><br>do_all_the_things does not have UB for any value of 'i' including null - but the compiler can't prove that. But at the do_all_the_things caller, once it's inlined and 'i' is seen to be null, the compiler can conclude that 'is_good_for_thing' must return false if 'i' is null, otherwise there would be UB, and delete the middle_thing call.<br><br>This code would be warning, static analysis (even global static analysis, if such were tractable), and dynamic analysis clean - yet still there remains (after inlining) dead UB code which the compiler can remove.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>So why the insistence that it should delete this “UB”</div><div>rather than warn, why the insistence that there not be an</div><div>option to get a warning rather than silently deleting, in</div><div>case the compiler found some “UB” that the static analyzer</div><div>isn’t yet capable of finding, and needs to be enhanced for.</div></div></blockquote><div><br>Except it doesn't or can't (interprocedural or inter-file analysis - may be impossible (separate compilation) or prohibitively expensive (too many paths)) - that's why we've built the dynamic analysis tools. And yes, if you find a place where LLVM deletes UB code that wouldn't've been diagnosed by -fsanitize=undefined - sounds like a great opportunity to enhance it! That would help users immensely, I'm sure.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>If Apple is still your employer, I think they would find it odd</div><div>that you are arguing against their established software</div><div>engineering principles.</div></div><div style="word-wrap:break-word"><div><br></div><div><br></div><div>Peter Lawrence.</div></div><div style="word-wrap:break-word"><div><br></div><div><br></div><div><br></div><div><br><div><blockquote type="cite"><div>On Aug 2, 2017, at 8:34 AM, Daniel Berlin <<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>> wrote:</div><br class="m_2389556901857625064Apple-interchange-newline"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Saying “The C++ language lets me assume that that won’t happen, & optimize </div><div>on that basis” is an assumption that that’s what the user wants, but you</div><div>haven’t asked you’ve just assumed, and AFAICT it is an incorrect assumption.</div></div></blockquote><div>This is actually an incorrect assumption on your part. Many users have been asked many many many times. This wasn't just done.</div><div>So please don't say "you haven't asked you've just assumed", because that is flat out wrong.</div><div><br></div><div>" and AFAICT it is an incorrect assumption."</div><div>This however, needs a citation to anything that is real data.</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 style="word-wrap:break-word"><div>What’s worse is that there isn’t any way to opt-out of this assumption</div><div>(-fsanitize=undefined isn’t opt’ing out, its opt’ing in to a lot extra that I</div><div>might or might not want).</div></div></blockquote><div><br></div><div>Correct, there is no way to opt-out except to use a different language (or at the very least, a different compiler, but i'm not aware of any that would meet your requirements in general).</div><div>Sometimes, you don't build something for every use case, and the answer is "if that's your use case, that's awesome, but it's not a thing we serve".</div><div><br></div><div><br></div></div></div></div>
</div></blockquote></div><br></div></div></blockquote></div></div>