Then the answer to the potential null+-1 being valid is simple, mandate in
the next standard that the 0+-PAGE_SIZE be premapped as sealed no rwx
pages. That resolves the problem completely. They don't need to have
anything mapped to them, just that they be mapped as invalid.

On Thu, 31 Jul 2025 at 15:17, Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Thursday, 31 July 2025 04:16:23 Pacific Daylight Time zxuiji via Std-
> Proposals wrote:
> > Uh, what is wrong with NULL? Nobody expects a pointer to be below
> > sysconf(SC_PAGE_SIZE) so regardless of if the pointer is incremented or
> not
> > one would recognise it as an invalid pointer while debugging.
>
> The standard doesn't *guarantee* that. The only officially-mandated
> invalid
> address is that of nullptr itself (which as others have said, doesn't need
> to
> be a bitwise zero). Strictly speaking, the address of (char*)nullptr + 1
> could
> be valid and could be the result of some memory allocation.
>
> In practice, it doesn't happen. In practice, the smallest granularity that
> virtual memory managers can control is a full page, so they make the full
> page
> containing nullptr invalid. And in practice nullptr is the lowest address
> in
> that page.
>
> Interestingly, the addresses before nullptr are by necessity invalid, not
> because one could decrement nullptr, but because you're not allowed to
> calculate one-past-the-end of a valid object and reach nullptr.
> Considering
> this depends on object size, everything prior to nullptr within
> "reasonable
> object size" is also invalid. In practice, that's also one page.
>
> Though in practice it's actually more than one page, for "defence in
> depth".
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>