<div dir="ltr"><div dir="ltr">On Tue, 21 Apr 2020 at 15:46, Arthur O'Dwyer 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:1px solid rgb(204,204,204);padding-left:1ex"><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" target="_blank">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:1px solid 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></div></blockquote><div><br></div><div>A major part of the purpose of point 4 of the policy is to prevent creation of language dialects, such as have unfortunately been created by (for example) the -fno-exceptions and -fno-rtti flags. If people can rely on uninitialized variables behaving as if initialized to zero, then they will write code that assumes that to be the case, and such code will not work in compilers / compilation modes that don't provide that language dialect. If people cannot rely on uninitialized variables behaving as if initialized to zero, then we mitigate the risk of creating a language dialect.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><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></div></blockquote><div><br></div><div>They are, of course, welcome to speak up and express that opinion. But note that one reason that people want zero-init to be used from a security perspective is to give a high chance that use of the uninitialized value (especially when it is a pointer) will crash, and issuing a trap instead is consistent with that. (Another reason is that zero is very unlikely to be an out-of-bounds array index, but issuing a trap in that case is likely more desirable than producing a wrong-but-in-bounds result.)</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 dir="ltr"><div class="gmail_quote"><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></div></blockquote><div><br></div><div>Please try to keep a respectful tone. Our policy in this area exists for a reason and is not "nonsense".</div><div><br></div><div>Any reasonable alternative that practically mitigates the risk of creating a language dialect, while still addressing the presented use cases, would seem in scope for discussion.</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 dir="ltr"><div class="gmail_quote"><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>
_______________________________________________<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="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>