<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 28, 2018, at 2:28 PM, Kostya Serebryany <<a href="mailto:kcc@google.com" class="">kcc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Nov 28, 2018 at 2:26 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:<br class=""></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;"><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Nov 28, 2018 at 2:18 PM JF Bastien via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></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;"><div style="word-wrap: break-word; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Nov 28, 2018, at 11:08 AM, Kostya Serebryany via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="m_-5256318323671994973m_6134788041857996776Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none;" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Nov 27, 2018 at 6:12 PM Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank" class="">richard@metafoo.co.uk</a>> wrote:<br class=""></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;"><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, 27 Nov 2018 at 11:52, Kostya Serebryany via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></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;"><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Nov 27, 2018 at 10:43 AM Sean McBride <<a href="mailto:sean@rogue-research.com" target="_blank" class="">sean@rogue-research.com</a>> wrote:<br class=""></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 Tue, 27 Nov 2018 10:19:03 -0800, Kostya Serebryany via cfe-dev said:<br class=""><br class="">>One more data point: among the bugs found by MSAN in Chrome over the past<br class="">>few years 449 were uninitialized heap and 295 were uninitialized stack.<br class="">>So, the proposed functionality would prevent ~40% (i.e. quite a bit!) of<br class="">>all UUMs in software like Chrome.<br class=""><br class="">I just lurk here, but I think the proposed functionality would be greatly appreciated by C/C++/Obj-C developers on macOS, where MemorySanitizer is not supported and valgrind can't even launch TextEdit. If I'm not mistaken, it would be the *only* tool on macOS to catch UUMs.<span class="m_-5256318323671994973m_6134788041857996776Apple-converted-space"> </span><br class=""></blockquote><div class=""><br class=""></div><div class="">It won't catch anything -- but it will prevent the stack UUMs from hurting you in production.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Well, it will prevent them from resulting in unbounded UB, yes, but that's not the only thing that hurts you.</div></div></div></blockquote><div class=""><br class=""></div><div class="">My statement above is applicable to both zero-initialize and pattern-/random-intialize. </div><div class=""> </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;"><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">A few years back I improved clang's -Wuninitialized and it found a few hundred bugs in one codebase. Of those, in only about half of the cases was the correct fix to zero-initialize; the uninitialized read was very often symptomatic of a logic bug in the function. Now suppose a compiler adds a flag to automatically zero-initialize. This will likely catch on, just like -fno-strict-aliasing did, because it makes it easier to write wrong code that appears to work, and there's a tendency to value code appearing to work more than you value it actually working. And before you know it, ~all large projects need to be built with that flag enabled all the time, because they depend on some code that expects uninitialized variables to be zero-initialized (say, in inline functions or templates). Now we lose an opportunity to catch lots of bugs (either at compile time or runtime), and the benefit is that we define away a similar number of bugs. I don't think it's clear that that's a good tradeoff.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I have absolutely no disagreement with what you say here. </div><div class="">I'd love to pass the bikeshedding phase and get the performance numbers, then come back to the discussion if the numbers show that zero-init is much faster. </div><div class=""> </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;"><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">Also, as others have noted, adding an "initialize to zero" flag will create an incompatible language dialect, just like -fno-strict-aliasing and -fno-exceptions and -fwrapv (etc) did. We have a general policy that we don't want to do that. Initializing to a pseudo-random or intentionally-chosen-to-often-trap bit-pattern seems fine to me, though, and an entirely reasonable security measure.<br class=""></div><div class=""><br class=""></div><div class="">Half-baked idea: what if we made it possible to enable a "zero-initialize all uninitialized variables" mode internally within the compiler but didn't expose it at all? (That way, you could turn this feature on with a compiler plugin, but a stock clang binary can't do it no matter what you write on the command line, unless you have such a plugin, which we don't ship with clang.)</div></div></div></blockquote><div class=""><br class=""></div><div class="">Interesting, but I don't know how easy it is to use a plugin in all environments where we need to measure perf. </div><div class="">IMHO, a scary-named flag that we periodically change (more frequently than every release) should work well enough. </div></div></div></div></blockquote><br class=""></div></div><div style="word-wrap: break-word; line-break: after-white-space;" class=""><div class="">Honestly this seems simple enough to support and use, and will clearly break people relying on it inadvertently. We should assume our users are adults and will get the message, and once we remove the option there should be no surprise.</div></div></blockquote><div class=""><br class="">I'm not sure it's really a matter of people not being adults, and going on past experience there does seem to be a real risk that people would grow a dependence on such behavior.<br class=""><br class="">Seems easier to me to separate the two pieces - move ahead with the non-zero options, and separate the discussion on the zero option. You can present performance numbers from what you can measure without shipping a compiler with the feature - and if those numbers are sufficiently compelling compared to the risks of slicing the language, then perhaps we go that way.<br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">This approach will significantly impair my ability to do the measurements I need. </div></div></div></div></blockquote><div><br class=""></div><div>Same, and I don’t intend to publish all the numbers that I can measure for the usual reasons.</div><div><br class=""></div><div>Further, I expect that other people’s codebases will behave differently, and I want those other people to be able to do their own measurements. I want to make their life easier, because the faster we iterate and remove performance issues, the faster we can get rid of zero-init because we trust that people’s experiments are representative enough to prove that there’s no significant performance cost left.</div><div><br class=""></div><div>By making measurements harder we’re hiding the actual cost of this feature, and keeping alive the myth that zero-init is better.</div><div><br class=""></div><div>By changing the flag name all the time we’ll make it hard enough to rely on the flag for its semantics, and it’s then trivial to remove the flag.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_quote"><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;"><div dir="ltr" class=""><div class="gmail_quote"><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;"><div style="word-wrap: break-word; line-break: after-white-space;" class=""><div class="">Is this the only remaining objection to the patch? I haven’t received comments on much otherwise, it would be good to get reviews going.<br class=""></div><br class=""></div>_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a></blockquote></div></div></blockquote></div></div></div></blockquote></div><br class=""></body></html>