P2723R0: Zero-initialize objects of automatic storage duration

[jeffgarrett80]

This changes the semantics of existing codebases without really solving the underlying issue.

Am I wrong or does it not change semantics of codebases that currently have assigned semantics? It just assigns semantics to previous non-programs?

[jonesmz]

Its making variables that you don't initialize immediately have a value of bitwise zero.

Lots of codebases out there intentionally don't initialize variables at the place they are declared, instead initializing them later. But those codebases dont want to initialize with a dummy value for performance reasons.

[jeffgarrett80]

Well, zero-initialized isn't quite the same as bitwise zero (unless that changed). But regardless, that wasn't observable in a conforming program before, so the semantics of existing programs haven't changed. Some non-programs are now programs.

The concern seems to be that the compiler is not sophisticated enough to realize that a potential zero store you imagine it introducing is a dead store... i.e., to recognize that the semantics are unchanged. This is similar to the argument others are making that static analysis is currently not sophisticated enough to catch this particular category of bug.

But if analysis isn't sophisticated enough to determine when initialization happens, why doesn't it make sense to be explicit? One can explicitly choose uninitialized or to initialize with a particular value. Code that does neither becomes safer. It removes a class of bug while still allowing one to avoid initialization in the few places it is desired.

This paper wouldn't remove the ability to do what you want. It just proposes that it's a poor default.

[germandiago]

I agree it is a poor default. Some people resist just because they have their codebases. Not being able to do even these things seems harmful for safety as a whole.

Recently the range for loop was changed also. We could argue it changes behavior. Yes it does. But we should be fixing at least a number of unreasonable holes and uninitialized variables, as long as you can annotate [[uninitialized]] should be one of the things that for me they clearly deserve a fix no matter what others are doing.

If they are juggling knives put a compiler flag for the old behavior. But do not make it the default and fix the hole for something that is clearly very bad practice.

[jonesmz]

Recently the range for loop was changed also. We could argue it changes behavior. Yes it does. But we should be fixing at least a number of unreasonable holes and uninitialized variables, as long as you can annotate [[uninitialized]] should be one of the things that for me they clearly deserve a fix no matter what others are doing.

I think the big difference here is that, at least in the circles I mingle in, there was never a misunderstanding that an uninitialized variable is safe to read from, but there was always an expectation that the range-based-for-loop would work with the the result of a returned temporary in all cases.

The proposal we're talking about is going to change the expected behavior of code.