<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Nov 20, 2018 at 2:21 AM Tim Northover via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 19 Nov 2018 at 23:26, Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>> wrote:<br>
> Le jeu. 15 nov. 2018 à 15:00, Tim Northover via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> a écrit :<br>
>><br>
>> On Thu, 15 Nov 2018 at 22:53, JF Bastien via cfe-dev<br>
>> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>> >   2. Zero initialization<br>
>> ><br>
>> >     Zero initialize all values. This has the unfortunate side-effect of<br>
>> >     providing semantics to otherwise undefined behavior, programs therefore<br>
>> >     might start to rely on this behavior, and that's sad. However, some<br>
>> >     programmers believe that pattern initialization is too expensive for them,<br>
>> >     and data might show that they're right. The only way to make these<br>
>> >     programmers wrong is to offer zero-initialization as an option, figure out<br>
>> >     where they are right, and optimize the compiler into submission. Until the<br>
>> >     compiler provides acceptable performance for all security-minded code, zero<br>
>> >     initialization is a useful (if blunt) tool.<br>
>><br>
>> I disagree with this. I think this is essentially defining a new<br>
>> dialect of C++, which I have massive concerns about. Additionally, as<br>
>> much as we might claim it's a transitional measure, we all know that's<br>
>> not how it'll be used in practice.<br>
><br>
> How is it different that other options like -fno-strict-aliasing or trap on sign integer wrap?<br>
> These are all options that are "defining new dialect of C++", yet are useful for some customers.<br>
> Why is it that bad to support a "new dialect" in these conditions?<br>
<br>
IMO, it's *not* very different but we were forced to support those for<br>
compatibility with GCC. I don't think people properly considered the<br>
implications of either of those when adding them. Where possible we've<br>
been trying to educate users and move them to sanitizers so that they<br>
can fix their code.<br>
<br>
Also, each additional dialect axis we add makes the problem exponentially worse.<br></blockquote><div><br></div><div>FWIW, I think there are other distinctions:</div><div><br></div><div>1) The strict aliasing difference is *much* smaller IMO, and in practice causes fewer issues. This may be happenstance because we relatively rarely optimize based on this, but the fact remains that I think this divergence will be much more rapid and significant.</div><div><br></div><div>2) I think wrapping math is relatively rarely *depended* on, and quite easy to fix by casting to unsigned.</div><div><br></div><div>On the flip side, I think automatic initialization is a much more slippery and steeper slope.</div><div><br></div><div>But perhaps the biggest issue is what Tim mentions at the end -- more dialects makes this worse, so the existence of initial dialects doesn't seem to argue for more being OK.</div><div><br></div><div><br></div><div>Also, we forgot to mention the biggest one: `-fno-exceptions`. Despite being very valuable to some users (including myself), it is .. extremely painful to have this divergence.</div><div><br></div><div>-Chandler</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers.<br>
<br>
Tim.<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>