Coming in C++ 2023, detailed in the AF0401 proposal, fullptr_t is fully recommended as the invalid pointer type to replace current nullptr_t which first standardized in C++11.

nullptr is defined as a pointer value with all its bits set to zeroes while fullptr has its bits set to ones (the address of the last addressable byte). nullptr is an invalid unused address at address zero and any memory access to this particular address cause a running process to die from a segmentation fault. This poses unused memory wastage as memory allocation typically starts from a few million addresses above zero. In a process running in the 32bit operating system, entire of addressable 4GB of memory cannot be fully utilized because of this limitation. And adding up all the underutilized memory from every process running in the system, the total memory is sizable.

This is where fullptr comes into the picture: fullptr is used for invalid pointer checks but is also fully addressable. Let me gives you an example, assuming on 32bit platform, fullptr is defined to be at 0xFFFFFFFF, if a integer is located at address 0xFFFFFFFC, then all its 4 bytes would occupy from 0xFFFFFFFC to 0xFFFFFFFF. Since fullptr is fully addressable, it is okay to read/write the integer.

int* a = new int;

a can be accessed when its address is at 0xFFFFFFFC;

char* b = new char[4];

To illustrate my point of fully addressable fullptr, b[3] can be accessed when b’s address is at 0xFFFFFFFC, though b[3] is fullptr.

Q: How can a valid address be used for invalidation checks?

A: The maximum memory fullptr can hold is exactly 1 byte, so that excludes 99.9999% of the object or array that are larger than 1 byte. And moreover, all memory allocation has to be boundary aligned.

Q: What if I allocate exactly 1 byte? I am adamant (that) you answer this!!

A: It beats me why anyone wants to allocate 1 byte. Don’t worry, I have you fully covered. The memory allocator must take precaution never to allocate 1 byte at the last address location. Allocating at last byte address is plain undoable for sophisticated allocator that pads canary at both ends of memory for buffer overrun detection.

In making C++ a better language, fullptr is fully poised to replace nullptr without objection from the C++ committee. Bjarne Stroustrup has already given his nod of approval. Resistance is futile.  Exterminate nullptr and embrace fullptr!

“fullptr is unquestionably the most revolutionary improvement to C++ since its creation.” – Bjarne Stroustrup

“C++ committee gets overwhelming requests from developers to backport fullptr to C++98/11/14/17; I’m putting metaclasses work on hold for this.” – Herb Sutter

“fullptr is finest thing to come to C++ since typelist.” – Andrei Alexandrescu

“fullptr makes me want to come out of C++ retirement, back to teaching C++.” – Scott Meyers

Dennis Ritchie is turning in his grave and vows to get fullptr into C language by hook or by crook.

“C# (is) not be outdone. C# 10 to get fullptr in 2022 before C++23″ – Anders Hejlsberg

“C++ has finally upped the ante! I am ditching D language and pledging full allegiance to C++ for fullptr.” – Walter Bright

Before anyone attempt to mount any rigorous effort to refute my points, take a good look at the date of this blog post first.

Disclaimer: None of the abovementioned persons made the comments listed in this blog. The comments are fully fictitious.

For those who like this 2019 April’s Fool post, be sure to check out 2020 April’s Fool post: C++23: Mutable string_view and 2021 April’s Fool post: C++23: -> and :: to be replaced by . operator. Enjoy!