<div dir="ltr"><div dir="ltr">On Tue, Apr 21, 2020 at 6:12 PM Richard Smith via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><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">What you're proposing is, without question, a language extension. Our policy on language extensions is documented here: <a href="http://clang.llvm.org/get_involved.html" target="_blank">http://clang.llvm.org/get_involved.html</a><div><br></div><div>Right now, this fails at point 4. We do not want to create or encourage the creation of language dialects and non-portable code, so the place to have this discussion is in the C and C++ committees. Both committees have processes for specifying optional features these days, and they might be amenable to using those processes to standardize the behavior you're asking for. (I mean, maybe not, but our policy requires that you at least try.)</div><div><br></div><div>However, there is a variant on what you're proposing that might fare better: instead of guaranteeing zero-initialization, we could guarantee that any observation of an uninitialized variable *either* gives produces zero or results in a trap. That is: it's still undefined to read from uninitialized variables -- we still do not guarantee what will happen if you do, and will warn on uninitialized uses and so on -- but we would bound the damage that can result from such accesses. You would get the security hardening benefits with the modest binary size impact. That approach would not introduce the risk of creating a language dialect (at least, not to the same extent), so our policy on avoiding language extensions would not apply.</div></div></blockquote><div><br></div><div>I dont understand the point you're making here.  You're saying that if Clang provides reliable behavior, that's a language extension and therefore impossible; but if Clang provides behavior that unpredictably switches between only two possible alternatives (zero or trap), then that's not a language extension anymore and therefore is possible?</div><div><br></div><div>I suspect many of the people quoted in the original quote-fest would not be happy with "zero <i>or trap</i>" as the two behaviors.</div><div>What if you made it "zero <i>or one</i>"?  That is, whenever you access an uninitialized variable, you are guaranteed to get either all-bits-zero or else all-bits-zero-except-for-the-last-bit-which-is-1?  Would that selection of two behaviors leave matters sufficiently unspecified so as to dodge this "language extension" nonsense?</div><div><br></div><div>Alternatively, what about "all-bits-zero or else we explode the physical computer," or "all-bits-zero or else we output a proof of Goldbach's conjecture"?</div><div><br></div><div>–Arthur</div></div></div>