Hacker News new | ask | show | jobs
by TuxSH 292 days ago
> Why bother with this category? The code exercising it is buggy either way

Because it is an actual security vulnerability if you cross privilege boundaries (infoleaks/(K)ASLR bypass, etc.), and one people often miss at that.

Say you write:

    struct { long long a; char b; } foo; foo.a = 0; foo.b = 1; return foo;
You end up leaking 7 stack bytes here (due to padding).

GCC's `-ftrivial-auto-var-init=pattern` currently initializes all unknown-value stack variables with 0xFEFEFEFE(...). This is usually an invalid fp value, invalid offset and invalid virtual address, allowing crashes to happen. This is a good thing.

Regarding performance, there is an attribute to opt out (both for the standard C++26 feature and the GCC option that is a subset of it)

1 comments

How does it prevent security vulnerabilities when instead of being undefined entirely, the behaviour is defined to be wrong? This is the "chug along at all costs" mentality that PHP has been slowly and painfully growing out of.

`-ftrivial-auto-var-init=pattern` doesn't need "erroneous behaviour" in the standard at all. In fact, it may outright conflict with it, if for example the standard defines that the compiler must initialize variables to zero instead of your chosen pattern in case of "erroneous behaviour".

"Erroneous behaviour" is a superfluous concept that exists only to allow the committee to pat themselves on the back and say "See? We no longer have undefined behaviour!".