On Thursday, 31 July 2025 08:39:22 Pacific Daylight Time zxuiji via Std-
Proposals wrote:
> It's still useful to have the range, take std:string(...) for example. It
> takes char const * str as an option for constructing with. With a
> definitely invalid range it could catch that and initialise to a state that
> could indicate the error in release mod while in debug mode it just carry
> on and let the segfault happen.

As Jason has just said: it doesn't catch "just outside" the range. And the
vast majority of invalid pointers will not be in the small ±4096 of nullptr,
so this doesn't solve the majority of bad pointer problems. I'm going to guess
that the most common problems of bad pointers are:
1) nullptr
2) dangling pointers
3) uninitialised memory used as pointers
4) 32-bit truncation of valid pointers

The proposal catches the first, but not the second, third, or fourth. I'd argue
that attempting to look into a pointer for invalidity around nullptr is a
waste of CPU cycles.

However, as I said in another email, it is useful to use a pointer variable to
store a value that isn't a pointer. This is very architecture-specific... and
yet works everywhere. Should this be standardised? I'd welcome so, just don't
know how.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Platform & System Engineering