hubert.reinterpretcast added a comment. In D68115#1686837 <https://reviews.llvm.org/D68115#1686837>, @jfb wrote:
> The entire point of this feature is to add guardrails to the language. I agree, and guardrails have a tendency to scratch paint if one drives against them. > What do people expect in the real world? Is there a cost to meeting these > expectations? The patch as-is moves past the scope of the `-ftrivial-auto-var-init` feature. The specific case I wrote the inline comment on is an instance where the initialization strategy appears deliberate and costs less space in the compiled binary than the case where the initialization strategy is hampered by trying to initialize bytes that are defined as holding indeterminate values. Paying for this extra space should require opting into (such as by using `-ftrivial-auto-var-init`). > If we put the pattern (0x00 or 0xaa) in the technically undef space, what > comes out? To extend the analogy, `0x00` seems to be the bumper car version in the context of the current discussion. Applications that have issues around uninitialized bytes in unions might be workable when using `0x00` as the pattern. With a non-bumper car pattern, it would become more clear to users when they are driving against the guardrails, so they aren't instead surprised when they fall off a cliff. 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
