Re: -ftrivial-auto-var-init in userland?

[enh <enh%google.com@localhost>]

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 <brooks%freebsd.org@localhost> 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