On Thursday, 31 July 2025 08:51:11 Pacific Daylight Time zxuiji wrote:
> My bad on the name, misread it. As for the "doesn't solve it at all", but it
> does. Think about it for a moment, if the MAX_INVALID_ADDRESS is always
> defined as at least 512 and the 1st & last page (using page for
> convenience, always relative to NULL) is always assigned as sealed
> non-access pages then any time those pages are referenced then a segfault
> is guaranteed to occur if it's not caught before hand for release/server
> stability purposes. That in itself is useful to catch erroneous code using
> uninitialised (as in no allocation made, not as in not assigned any solid
> value) buffer pointers during debugging.

Again, disagree. An *uninitialised* pointer is unlikely to have the top 52-55
bits set exactly the same. It's not impossible because those are "small
integers", but it the likelihood is too low to be useful for debugging.

The original proposal in this thread was to catch arithmetic on nullptr,
because pointers by ±512 bytes or less is reasonable. So I agree on
*recommending* the first and last pages be marked inaccessible because it's a
good practice, I don't see the need to *mandate* it. Manipulating the nullptr
is already UB, so marking those pointer values around it also invalid doesn't
make anything less UB. Likewise for using uninitialised memory as a pointer...
or as anything else.

We have other memory debugging tools. And the first and last pages *are*
inaccessible in any modern OS anyway. For example, on FreeBSD:
http://fxr.watson.org/fxr/source/kern/kern_exec.c?im=10#L150

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