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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
