Compilers should add this as a non-standard extension, right? -ftrivial-auto-var-init=zero is a partial solution to a related problem, but it seems like they could just... not have UB here. It can't be that helpful for optimization.
Yes but it’s not portable. If zero initialization were the default and you had to opt-in with [[uninitialized]] for each declaration it’d be a lot safer. Unfortunately I don’t think that will happen any time soon.
You probably don't want zero initialization if you can help it.
Ideally, what you want is what Rust and many modern languages do: programs which don't explain what they wanted don't compile, so, when you forget to initialize that won't compile. A Rust programmer can write "Don't initialize this 1024 byte buffer" and get the same (absence of) code but it's a hell of a mouthful - so they won't do it by mistake.
The next best option, which is what C++ 26 will ship, is what they called "Erroneous Behaviour". Under EB it's defined as an error not to initialize something you use but it is also defined what happens so you can't have awful UB problems, typically it's something like the vendor specifies which bit pattern is written to an "unintialized" object and that's the pattern you will observe.
Why not zero? Unfortunately zero is too often a "magic" value in C and C++. It's the Unix root user, it's often an invalid or reserved state for things. So while zero may be faster in some cases, it's usually a bad choice and should be avoided.
> Ideally, what you want is what Rust and many modern languages do: programs which don't explain what they wanted don't compile, so, when you forget to initialize that won't compile.
I think you're confusing things. You're arguing about static code analysis being able to identify uninitialized var reads. All C++ compilers already provide support for flags such as -Wuninitiaized.
Uninitialized variables reads can only sometimes be detected statically. -Wuninitialized is still good, but it will miss a lot of cases when the read is in a different translation unit. Whole program analysis could get more cases, but with large programs (multi-million lines of code) it is unlikely we can analyze everything (everything being more than just variables) before the universe ends - see the halting problem.
> Uninitialized variables reads can only sometimes be detected statically. -Wuninitialized is still good, but it will miss a lot of cases when the read is in a different translation unit.
From my experience, you're exaggerating the number of false negatives, which is more a factor of how you write your code than what static code analyzers do.
Also, your comment reads like an attempt at moving the goal post. We start this discussion being very adamant in accusing C++ of being impossible to detect uninitialized var reads. Once that assertion is thoroughly proven to be false and resulting from clueless ignorance, now we try to reframe it as being... Imperfect in some hypothetical scenarios? So what's supposed to be the actual complain?
The main problem with C++ is that some people somehow are personally invested in criticizing it from a position of complete ignorance. The problem is not technical, it's social.
I agree false negatives are rare - I was intending to temper expectations because perfection is impossible.
> You're arguing about static code analysis being able to identify uninitialized var reads.
(Safe) Rust does guarantee to identify uninitialised variable reads, but I believe the point is that you can get the optimisation of not forcing early initialisation in Rust, you just have to be explicit that that's what you want (you use the MaybeUninit type); you're forced to be clear that that's what you meant, not just by forgetting parens.
You can even write e.g. this:
let mut jim: Goat;
// Potentially much later ...
if some_reason {
jim = make_a_new_goat();
} else {
jim = get_existing_goat();
}
use(jim); // In some way we use that goat now
But, if we screw up and make it unclear whether jim is initialized, probably because in some cases it wouldn't be - that doesn't compile.
This is the usual "avoid early initialization" C++ programmers are often thinking of and it doesn't need MaybeUninit, since it's definitely fine if you're correct, it's just that the C++ compiler is happy (before C++ 26) with just having Undefined Behaviour if you make any mistakes and the Rust compiler will reject that.
[Idiomatically this isn't good Rust, Rust is an expression language so we can just write all that conditional if-else block in the initializer itself and that's nicer, but if you're new to this the above works fine.]
> (Safe) Rust does guarantee to identify uninitialised variable reads (...)
That's great. You can get that check on C++ projects by flipping a compiler flag.
Aren't we discussing C++?
What flag do you have in mind? (To the best of my knowledge, no such flag exists -- unless you're talking about one of the heavily penalized sanitizer modes.)
> To the best of my knowledge, no such flag exists
Your knowledge doesn't seem to even reach the point of having googled the topic. If you googled it once, you'd not be commenting it doesn't exist. Hell, you don't even seem to have read the thread, let alone the discussion.
Again with the personal attacks.
I'll note that you have failed to name this "obvious" flag that I'm missing.
Something like that is heading into C++26 actually. Except the initialization is not to zero, but to some unspecified value (with explicit intention of not allowing leaking garbage) and allowing to trap. It's called "erroneous values".
I don't really care if it isn't portable. I only have to work with Clang, personally.
> If zero initialization were the default and you had to opt-in with [[uninitialized]] for each declaration it’d be a lot safer.
I support that, too. Just seems harder than getting a flag into Clang or GCC.
> I don't really care if it isn't portable.
You don't care because your job is not to ensure that a new release of C++ doesn't break production code. You gaze at your navel and pretend that's the universe everyone is bound to. But there are others using C++, and using it in production software. Some of them care, and your subjective opinions don't have an impact in everyone else's requirements.
> I only have to work with Clang, personally.
Read Clang's manual and check what compiler flags you need to flip to get that behavior. It's already there.
Lmao. You've misread both of my upthread comments and have somehow arrived at the conclusion that this justifies personal attacks. There's just no discussion to be had here.
Gcc already has [[gnu::uninitialized]] (clang doesn't, AFAIK), as well as -ftrivial-auto-var-init=pattern which exactly matches the new C++26 semantics, if I'm not mistaken
> -ftrivial-auto-var-init=pattern
I believe this only helps for trivial automatic variables; not non-trivial automatic variables (structs/classes) that contain uninitialized trivial members.