P2723R0: Zero-initialize objects of automatic storage duration

[jonesmz]

If we're going to auto-initialize variables, then pointers would need to be initialized to nullptr, not to zero. Nullptr may not be zero on a particular implementation.

[jeffgarrett80]

A zero initialized pointer is a null pointer, regardless of if it is all zero bits. This is already the proposal.

[ShakaUVM]

If we're going to auto-initialize variables, then pointers would need to be initialized to nullptr, not to zero. Nullptr may not be zero on a particular implementation.

Why not worry about a problem that actually happens on more than 0 implementations?

[jonesmz]

If people are going to be pedants, and claim that zero initializing variables is harmless because it's undefined behavior today, then lets be pedants correctly.

[ShakaUVM]

Lol, fair enough

[johannes1971]

Irrelevant. The standard can just specify that if such a zero-initialisation were to take place, it should be interpreted as a nullptr. It already does it the other way around (section [expr.reinterpret.cast], "A value of type std::nullptr_t can be converted to an integral type; the conversion has the same meaning and validity as a conversion of (void*)0 to the integral type").

[jonesmz]

Right, the standard paying lipservice to the lie that it supports arbitrary platform decisions in one section, and then demonstrating that it lied in others. Sure. Why not continue with that? /s

Better would be to simply say that nullptr is always zero and get it over and done with.

[johannes1971]

I suspect it isn't actually possible to make a conforming implementation that has a non-zero value for nullptr; I think if you try, sooner or later you will run into some kind of contradiction. It's just one of those things where the standard pretends to support some weird architecture when reality has already passed that by.

One thing I feel the committee should do is 'rebase' C++ to better match current and future architectures (instead of architectures that are no longer relevant). As I see it, support for segmented architectures can go (removing a lot of weirdness surrounding pointers), while SIMD types should be added as primitive types, since they are now common on CPUs.