fwiw, android has shipped with -ftrivial-auto-var-init=zero for years now, with only a handful of arrays that needed __attribute__(__uninitialized__) for performance. (we upstreamed the ones we found in third-party open source, so you won't need a local hack for, say, pcre2, which had a large [but safe] stack array on a hot path.)
the security properties of =zero and =pattern are quite different, which is why android uses zero for all architectures, despite that not generating the smallest code size for all architectures. iirc the "zero for release builds and pattern for debug builds" idea came up but the difficulty of educating everyone and the effective dilution of testing meant it's only there as a "set an environment variable and rebuild" option. i don't think that's even used for fuzzers, so it's possible it's just historical cruft that should be removed at this point. (does zero initialization everywhere mean we're effectively using a different dialect of c and c++ where some incorrect code "just works"? yes, but since it's a clearly _better_ dialect, only the most extreme language lawyers had any resistance to it.) On Wed, Jul 22, 2026 at 5:43 AM Brooks Davis <[email protected]> wrote: > > On Mon, Jul 20, 2026 at 09:34:29PM +0000, Taylor R Campbell wrote: > > I propose to enable -ftrivial-auto-var-init for all libraries and > > utilities in userland by default (under gcc and clang), and > > specifically to zero-initialize local variables in release builds and > > to nonzero-initialize them in current builds. > > > > See https://mail-index.netbsd.org/tech-kern/2026/07/20/msg031158.html > > for background. If there's any userland-specific considerations to > > discuss, we can discuss in this thread here. > > The one mostly userland-specific issue I know of it is that the original > implementation would unconditionally zero all stack variables, even > ones used only in branches. One of the SPEC2006 benchmarks has code > along the lines of: > > rettype > frequently_called_function(args) > { > /* reasonable set of stack variables */ > char error_buffer [4000]; > > ... > > if (error) { > snprintf(error_buffer, sizeof(error_buffer), ...); > ... > } > > } > > The compiler would always zero error_buffer even in paths were it wasn't > touched and didn't escape. The result was a significant performace > degredation. Such cases aren't common (and mostly don't exist in the > kernel where we have better stack discipline), but it's something to be > aware of. I belive modern version of LLVM have dealt with the worse of > these mis-optimizations. > > -- Brooks
