|
|
|
|
|
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) |
|
`-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!".