<div dir="ltr"><div dir="ltr">Hey Tim,<br><br><div class="gmail_quote"><div dir="ltr">Le jeu. 15 nov. 2018 à 15:00, Tim Northover via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">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.</blockquote><div><br></div><div>How is it different that other options like -fno-strict-aliasing or trap on sign integer wrap?</div><div>These are all options that are "defining new dialect of C++", yet are useful for some customers.</div><div>Why is it that bad to support a "new dialect" in these conditions?</div><div><br></div><div>Cheers,</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div><br></div><div><br></div><div> </div></div></div></div>