Initially concerns have been raised that -ftrivial-auto-var-init=zero
potentially defines a new dialect of C++, therefore this option was
guarded with
-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang.
The guard flag name suggests that at some point
-ftrivial-auto-var-init=pattern will perform on par with
-ftrivial-auto-var-init=zero, thus making it possible to remove the
latter from Clang.
However this isn't going to happen in the nearest future, at least not
on X86, where memset(object, 0, size) is still lowered to a more
efficient code than memset(object, 0xAA, size).
Therefore security-minded people may still need an easy way to
zero-initialize all the locals to keep the performance penalty low.
For Linux kernel, which already uses a non-standard dialect of C,
introducing yet another hardening feature doesn't radically change the
situation. Other C codebases also tend to use non-standard features more
often, so the mentioned guard flag only complicates the adoption of
auto-initialization for them, not actually protecting their purity.
As a compromise solution, let
-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
remain mandatory for -ftrivial-auto-var-init=zero in C++ mode and make
it optional in the C mode.