On April 1^st of 2018, I read Rainer Grimm’s No New New: Raw Pointers Removed from C++, an April Fool joke. I thought to myself I could do better. I came up with three jokes in a flash of inspiration. I decided to post one each year, starting with the best one. In 2019, I posted the C++23: fullptr to replace nullptr where I lied about the invalid address pointer type changed from zero to maximum address in C++23. Since then, there have been views every day. Who says you can only read April Fool’s post on that day of the year? I set up this C++ blog to share my expertise in the hope that future hiring managers may take notice of me. Instead, it has become a C++ April Fool joke website. *I am crying at this moment as I am typing this.*

I guess I owe it to my readers to update the feasibility of fullptr. You may want to read the fullptr joke if you haven’t before continuing this feasibility report. To keep the scope manageable, I restricted my research to Windows desktop user mode applications running on Intel architecture based on Windows Internals book and Pluralsight course by Pavel Yosifovich. The slides shown here are courtesy of the Pluralsight course. I briefly scanned through the macOS and iOS Internals by Jonathan Levin. There is no information on a maximum addressable memory address. As for Linux, there is only an ancient book published in 2005 on 32-bit OS. I have to admit I am more of a Windows guy than a MacOS or Linux one. Let’s begin.

On 32-bit Windows, the addressable range for user space is 0 to 2GB while the range of system space is 2GB to 4GB. If LARGEADDRESSAWARE is specified in the linker option and provided that Windows is enabled to handle large address, user space is increased from 2GB to 3GB at the expense of the kernel mode programs. On 64-bit Windows, for a 32-bit large address enabled user process, the space is increased to 4GB.

Intel 64-bit processor enables up to 48-bit for memory addressing. However, for earlier Windows like 7 and 8, Microsoft decided to support up to 44-bit (8TB for user mode space and another 8TB for system space). The latest Windows 10/11 supports up to 48-bit which means 128TB for user space and 128TB for system space. The diagram above shows that the user and system space is separated by a region of unmapped address and fullptr can be accessible from system space, not user space. The Sunny Cove Intel microarchitecture increases the memory size to 57-bit (128 PB) which Microsoft Windows has not caught up to support the full range.

On Windows, the granularity of memory allocation from the heap manager is 8 bytes. It is impossible to allocate purely 1 byte. If you request 1-byte memory, the heap manager allocates 8 bytes and returns you the 1^st byte. The fullptr post falsely states “This (nullptr) poses unused memory wastage as memory allocation typically starts from a few million addresses above zero”, this is the implementation of Windows, nothing to do with nullptr or fullptr.

To summarise, user mode programs can’t access the fullptr unless it is a 32-bit user mode program with large address aware enabled, running on 64-bit windows. System programs such as kernel drivers can access fullptr but this is not focus of this report. And it is not possible to allocate 1-byte on windows and wastage of the range of memory address above zero address cannot be avoided as this is how Windows chose to implement it this way.