That seems like a mistake to turn on, given that clang also has options to error on uses of potentially uninitialized variables. Zero is often just as wrong as any other value, so this flag will hide real bugs.

In fact, I'd rather have a flag that clobbers values with random data, to make sure that uses of uninitialized values are caught as soon as possible.

> error on uses of potentially uninitialized variables.

This is absolutely the best option. That said,

> I'd rather have a flag that clobbers values with random data.

That's roughly what happens in practice as is, doesn't it? Barring the first option I'd rather have an option that fails predictably and reproducibly. An arbitrary but deterministic garbage number maybe? Like --set-uninitialized=0xdeadbeef. That might be getting too elaborate, haha.

Why not use static code analyzers? You run them in compilation time and warn you of uninitialized variables.

Initializing values just because seems wasteful. That's why global and static variables are already initialized in this way.

For me it would yet make sense that Gcc allows it even if it's not a very good practice it may have its uses.

Because static analyzers today are imprecise. We're considering where this makes sense to turn on in Android, and even within the Linux kernel.

If you can I would at least advise running tests using memory sanitizer, which is also built in to newer clang versions. They're much more precise, but only catch problems occurring at runtime. also adress sanitizer for the out of bounds accesses, use after free bugs, memory leaks etc.

We do. Also, the people who built msan are literally the ones implementing the initialization patterns.

Nice, sorry, I didn't notice you actually meant working on Android.

Great work btw. I've found a few actual bugs with ASan and MSan already. Not once a false positive.

what’s the reason gcc wouldn’t support it?

[edit] ipad auto correct

Because zero is not a correct value for all variables, and picking a random behavior over no behavior breaks ubsan.

It also adds a data-dependency (zeroing out a stack buffer depends on the length of the buffer) which is insecure.