is this your CVE-2019-6208?
Conversation
-finit-local-zero is a Fortran language option. I don't think there's any switch for default zero initialization in C or C++ in GCC. It was implemented in Clang, but exposed by the frontend in a way that makes it unlikely that there will be adoption.
gcc.gnu.org/onlinedocs/gfo
1
2
Clang implementation is intended to be production quality along with having useful features for debugging (not just zero bytes for hardening) but they don't want it to be a way to get well-defined semantics for uninitialized variables as a new language dialect. It's still a bug.
1
1
Since if it was defined as zeroing, it wouldn't be possible to detect uninitialized variable usage. The better solution to the problem is outright preventing uninitialized variable usage like Rust without having any default, just forcing init before usage based on control flow.
1
1
C compilers don't have an option for that, since code wasn't written for strict init before use semantics. Their uninitialized variable warnings are very conservative to avoid false positives. `int x; foo(&x);` won't warn even though it's local analysis and can't know it's safe.
1
It would certainly be possible for them to add an option for a dialect with strict initialization before usage. It's one tiny problem among many larger ones though, and trying to go down the path of making a safe dialect leads to something much worse than a modern safe language.
1
A similar case is signed integer overflow being undefined. That can be a good thing for security because -fsanitize=signed-integer-overflow -fsanitize-trap=signed-integer-overflow is fully standards compliant and only catches bugs. Using the unsigned checks is a lot more work.
In Rust, the choice was considering both signed and unsigned overflow a bug. It has to be explicitly done via wrapping operations. However, it's never undefined like C. It wraps by default in release and traps in debug with the intent to trap in release on future hw with support.