kees added a comment. In D125142#3502732 <https://reviews.llvm.org/D125142#3502732>, @MaskRay wrote:
> This cannot be committed as is. In particular, @rsmith's "We do not want to > create or encourage the creation of language dialects and non-portable code," > concern on > https://discourse.llvm.org/t/making-ftrivial-auto-var-init-zero-a-first-class-option/55143/2 > (shared by someone else) will be affected, I'd like to see that they lift > their concerns. FWIW, I think this concern was addressed back when `-ftrivial-auto-var-init` was added: uninitialized variables are considered UB, and the compiler would warn about them with `-Wuninitialized`. The coverage of `-Wuninitialized` was expressly not changed, so code will still warn about the uninitialized variable usage (but the actual contents of that variable is now at least constant). The point being, the dialect remains unchanged and the portability remains unchanged; it is only the safety of the resulting binary that is now improved. i.e. the UB still exists (the logic of the code may not match the content of the variable), but it's predictable now, instead of being potentially controllable by external factors (i.e. the prior stack contents, which may be controllable across privilege boundaries <https://outflux.net/slides/2011/defcon/kernel-exploitation.pdf>). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D125142/new/ https://reviews.llvm.org/D125142 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
