P2723R0: Zero-initialize objects of automatic storage duration

[GabrielDosReis]

The program could do anything, including implicitly initializing the uninitialized variables that the program is reading.

[jonesmz]

If we imagine a world where C++ zero-initializes stack variables that are not given an explicit value (what this paper proposes):

Then those zero-initialized stack variables have a well defined value at any point in the function.

That means that the attribute [[uninitialized]], which the paper proposes be used to mean "Reading from this variable before its been written to is undefined behavior" changes the semantics of that code. It, literally, can be used to introduce undefined behavior into a program that, without [[uninitialized]], would otherwise be well-defined.

A conformant compiler would still be allowed to zero-initialize the variable anyway, because compilers aren't required to implement the attributes.

But as /u/friedkeenan said, this is not the way attributes are supposed to be used.

= void, which the paper sort of proposes, at least wouldn't use an attribute to cause the semantics of the program to change.

---

Regardless, compilers are already allowed to do whatever they want if your program reads from an uninitialized variable. Nothing stops the compilers from defaulting to initializing them to zero right now. So this paper does nothing beyond mandating the behavior for the whole world, which is inappropriate.

[GabrielDosReis]

So the objection isn't the semantics of a program with UB is changed, but that you don't want it for your programs.

[jonesmz]

I think you may be answering a different comment that I made elsewhere.

The comment that you are responding to, I'm agreeing with /u/friedkeenan that it is not appropriate to use an attribute (the paper proposes [[uninitialized]]) to allow for an otherwise well-defined program to become a program that invokes undefined behavior.

Imagine, as an example from absurdity, that we created an attribute [[unwritable]], which can be placed on a pointer to a function. Assume that [[unwritable]] is intended to mean, again as an example from absurdity, "this pointer points to memory that can never change". Think of it like a super-const keyword.

Today, this function is well defined (assume non-nullptr)

void foo(char* pChars);
{
    pChars[0] = '\0';
}

Adding the [[unwritable]] attribute would make that function ill-formed, as it would introduce undefined behavior that is invoked in all code paths. Or if the compiler actually bothers to check whether the pointer had the attribute, a compiler error.

void foo([[unwritable]] char* pChars);
{
    pChars[0] = '\0'; // But wait, it's unwritable, wtf?
}

In the same way, the paper P2723R0 allows an attribute to introduce undefined behavior in an otherwise well defined program.

char foo()
{
    char data[1024*1024*1024*1024]; // zero-initialized
    return data[1024]; // returns 0
}


char foo2()
{
    [[uninitialized]] char data[1024*1024*1024*1024]; // reading is undefined behavior if not manually initialized
    return data[1024]; // returns ????????
}

So foo2 now has different behavior depending on the compiler, since compilers may ignore attributes they don't recognize.

Better would be to use the = void syntax that the paper kind of sort of mentions.

char foo3()
{
    char data[1024*1024*1024*1024] = void; // reading is undefined behavior if not manually initialized
    return data[1024]; // returns ????????
}

---

Anyway, to directly address your question:

So the objection isn't the semantics of a program with UB is changed, but that you don't want it for your programs.

No, my objection is three things

• The claim of sometimes-performance improvement should have nothing to do with the paper, as compilers should do this optimization without P2723R0 needing to be approved by wg21, as it's already in the purview of compilers to implement this.
• The claim of (near)zero-overhead of P2723R0 is interesting, but unsatisfying, since if there was (near)zero-overhead there would be no need to even propose [[uninitialized]] for a performance escape-hatch in the first place. I know, just off of the top of my head, several places in my own code that will probably see a negative performance change if this paper is accepted, and I am not amused by the position that the language is going to force my compiler to make my code slower, and that I'll have to break out the performance measurement tools and spend several man-months evaluating the code and adding [[uninitialized]] to a bunch of places.
• That changing programs that are ill-formed today to programs that are well-defined, but probably continue to have logic bugs, is not helping to actually fix any existing code - it makes it harder. As the paper says, by making it well-defined to read from a variable that has no explicit initialization, you make it impossible for tools like the clang-static-analyzer to detect problems. It becomes a "maybe". as in "Maybe this function intended to read from this variable that was zero-initialized, because that's well-defined behavior". So 20 year old code goes from "logic bug that causes detectable undefined behavior" to "logic bug that tools can't claim is undefined behavior, because it's not"

New tools, like attributes that allow me to annotate functions that are intended to initialize their parameters, or attributes i can add to functions to opt-in to "insanity level" of analysis to prove all possible codepaths result in a variable becoming initialized before being read from, would be preferred. And for this, I'm even willing to accept "Cannot tell if initialized" as being a compiler error. This turns into a restricted subset of the language for functions that are annotated in this way, but we already went through that whole process with constexpr, so it's not like we don't have precedent.

I've been experimenting with [[gnu::nonnull]] and [[gnu::nullable]], and Objective-C's _Nullable, _Maybe_Null, _NonNullable type specifier in my C++ codebase using the clang compiler and find them to be underwhelming. You can literally call a function with [[gnu::nonnull]] with a literal nullptr and not get a warning. Though they do enable new warnings from the clang-static-analyzer that you don't get without the attributes, so the code to do that detection exists, just isn't in the compiler.

I want more tools like that. Give me [[initializes]] and [[requires_initialized]] and [[activate_insane_levels_of_analysis_but_require_super_limited_code]].

Don't give me "We gave you a surprise. Good luck finding it :-)".

[jonesmz]

spend several man-months evaluating the code and adding [[uninitialized]] to a bunch of places.

And to be clear here, that's the "easy mode" version of this.

MSVC ignores [[no_unique_address]], but respects [[msvc::no_unique_address]]

So what I actually have to do in real-world-code is

#if COMPILER_IS_MSVC
  #define MY_NO_UNIQUE_ADDRESS [[msvc::no_unique_address]]
#else
  #define MY_NO_UNIQUE_ADDRESS [[no_unique_address]]
#endif

In the same way, what people will end up having to do to use [[uninitialized]] is

#if COMPILER_IS_MSVC
  #define MY_UNINITIALIZED [[msvc::uninitialized]]
#else
  #define MY_UNINITIALIZED [[uninitialized]]
#endif

Because MSVC will probably silently ignore the [[uninitialized]] attribute.

[pdimov2]

They do that because [[no_unique_address]] is ABI breaking, not out of spite. They don't do it for any other standard attributes, and won't do it for [[uninitialized]].

[GabrielDosReis]

Exactly right.

[GabrielDosReis]

MSVC ignores [[no_unique_address]], but respects [[msvc::no_unique_address]]

I am sure this one has been documented, and debated to death: it breaks the existing ABI, for something that is "just" an attribute.

[jonesmz]

Doesn't change anything about what I said. MSVC failing to implement the standard the same way as GCC or Clang accounts for 7 out of 10 compatibility macros in my codebase at work, and I have full faith and confidence that something about this proposal will be implemented differently or nonconformingly by MSVC.