There is a way usually on an OS to determine whether or not a particular
address is mapped (linux, for example, you can examine `/proc/self/map`).
However, this does not tell you the whole story. Just because there is
memory behind a pointer does not mean there is an object there. You might
read nonsense used as a scratch register. If you write, you might overwrite
a spilled register, or a data structure the compiler is maintaining.
Or if there is an object there, you might not have a pointer *to* that
object, and the compiler is free to assume that memory. Or the compiler
might simply examine the operation in its entirety and simply throw out the
access and replace it with a no-op read, a trap instruction, or simply
fallthrough to whatever codepath happens to be adjacent. That the memory
won't trap on raw (asm level) access is insufficient for determining
validity. You must also face down the beast of the C++ compiler,
the optimizations of which take no prisoners and give no quarter.

On Sat, 2 Aug 2025 at 13:01, David Brown via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On 31/07/2025 17:26, Sebastian Wittmeier via Std-Proposals wrote:
> > I was suggesting a function that returns true, if the address pointer is
> > definitely invalid; not a definitely invalid range.
> >
> > There are microcontrollers running C++ with 16-bit pointers.
> >
> > There are 64-bit systems running C++ with pages of several megabytes or
> > even 1 GiB.
> >
> > Doing pointer arithmetic on invalid pointers is UB.
> >
> > So the function below could not be implemented as a user function, but
> > would have to be inside the standard library.
> >
> > Is there any advantage of guaranteeing an invalid range around the
> > nullptr with a minimal size compared to leaving it as QoI to the
> > implementation?
> >
>
> There are microcontrollers supporting C++ with 16-bit pointers where
> there are /no/ invalid pointers - all are valid. (Dereferencing a null
> pointer is UB in the standard - an implementation is free to consider it
> as valid defined behaviour if it chooses.) It is common for
> microcontrollers to have a reset vector, part of an interrupt table, or
> the start of the program ROM or flash at address 0. And it is common
> for software to access this, such as for running integrity tests on the
> code storage.
>
> So it is perfectly reasonable to have C++ platforms for which there are
> no pointers that are invalid for at least some behaviours (such as read
> access as lvalues of unsigned char or std::byte).
>
> Conversely, on most modern platforms (32-bit or 64-bit), the vast
> majority of pointers are invalid for any kind of access. And even those
> pointers that /are/ valid for something, are usually invalid for other
> kinds of access. And there is no feasible way for an implementation to
> determine if a given pointer is valid or not, for any possible purpose.
> (That would require a VM and/or a managed environment, far too much
> overhead for typical C++ usage outside of debugging and sanitisers.)
>
> So what possible use could there be for a function called
> "isptrinvalid()"? If it returns true, the pointer is invalid. If it
> returns false, that does not tell you that the pointer is valid - it
> might still be invalid. The function could just as well be implemented
> as "returns false;" and give you just the same information. But that
> would clearly be a useless and misleading function.
>
> There really is nothing that could be implemented by C++ compilers, or
> useful to C++ programs, that goes beyond simply comparing a pointer to a
> null pointer as specified in C since the beginning.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>