[cfe-dev] making -ftrivial-auto-var-init=zero a first-class option

[Arthur O'Dwyer via cfe-dev]

On Tue, Apr 21, 2020 at 6:12 PM Richard Smith via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> What you're proposing is, without question, a language extension. Our
> policy on language extensions is documented here:
> http://clang.llvm.org/get_involved.html
>
> 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.)
>
> 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.
>

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?

I suspect many of the people quoted in the original quote-fest would not be
happy with "zero *or trap*" as the two behaviors.
What if you made it "zero *or one*"?  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?

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"?

–Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200421/56a5c6aa/attachment.html>