kees added a comment. In D125142#3505767 <https://reviews.llvm.org/D125142#3505767>, @jfb wrote:
> I think the most relevant post from @rsmith is: > https://discourse.llvm.org/t/making-ftrivial-auto-var-init-zero-a-first-class-option/55143/40 > > He has a prototype: https://reviews.llvm.org/D79249 > I assume he would like someone to pursue it further, it was a good faith > attempt at not just demanding. I'd played with it and it needed a few fixes, > but overall it was pretty complete. Does someone want to give it a go? That's a different mode and doesn't seem to be relevant to the current situation and this change to drop the -enable flag. > The fact remains that people have deployed zero init widely (you're likely > running multiple zero-init codebases to read this), and they would not ever > deploy zero-or-trap init. That's simply a fact. Right. > Separately, we'd discussed narrowing the performance gap between pattern and > zero-init, @Florian and team had done a bunch of work 2+ years ago, but I > don't know how "done" we can claim that work is since I haven't been tracking > the work. Performance is the smaller part of why init=zero is being used so widely. It's about stability. Quoting from my earlier thread <https://lists.llvm.org/pipermail/cfe-dev/2020-April/065221.html>: > Another driving factor (see below from various vendors/projects), is the > security stance. Putting non-zero values into most variables types ends > up making them arguably more dangerous than if they were zero-filled. > Most notably, sizes and indexes and less likely to be used out of bounds > if they are zero-initialized. The same holds for bool values that tend > to indicate success instead of failing safe with a false value. While > pointers in the non-canonical range are nice, zero tends to be just > as good. There are certainly exceptions here, but the bulk of the > historical record on how "uninitialized" variables have been used in > real world exploitation involve their being non-zero, and analysis of > those bugs support that conclusion. This "usually handled safely" state (e.g. existing NULL pointer checks) is specifically why Chrome OS switched from init=pattern to init=zero. 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
