[PATCH] D68115: Zero initialize padding in unions

Mon Apr 6 09:12:05 PDT 2020

hubert.reinterpretcast added a comment.

In D68115#1962892 <https://reviews.llvm.org/D68115#1962892>, @rsmith wrote:

> In D68115#1962863 <https://reviews.llvm.org/D68115#1962863>, @jfb wrote:
>
> > In D68115#1962833 <https://reviews.llvm.org/D68115#1962833>, @rsmith wrote:
> >
> > > I think the majority opinion expressed on this review at this point favors not guaranteeing zero-initialization except where required by the relevant standard. That'd also be consistent with our stance on trivial auto variable initialization in general.
> >
>

That's my view regarding the default behaviour with or without `-ftrivial-auto-var-init=pattern`, but I believe that there are cases where `-ftrivial-auto-var-init=pattern` is known to cause trouble for user code (due to the code having what is strictly uninitialized union padding).

[ ... ]

>>> I'm not yet sure about whether we want separate controls for this and for `-ftrivial-auto-init`, or whether from a user's perspective there's really only one question: should bits left uninitialized be `undef`, guaranteed zero, or guaranteed to be filled with a pattern -- independent of whether they're padding bits? (And related, do we actually want control over zeroing union padding in all cases or only for trivial automatic variables? And do we want control over zeroing or pattern-filling objects allocated with `new` with trivial initialization?)

I have found that users are less convinced that uninitialized union padding is something to fix in user code than for cases where a variable is missing an initializer and nonetheless accessed without a prior assignment.

> And we do not initially provide any guarantees as to what happens to padding within objects of other storage durations beyond what the language spec requires. (We might at some point in the future, but that would be behind a separate flag from `-ftrivial-auto-init`.) I'd be happy with that approach. Does that address everyone's concerns?

There's a chance that "point in the future" is now (and a separate flag was proposed).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68115/new/

https://reviews.llvm.org/D68115