sebastian as I just mentioned in my previous email it's in detecting
pointers from buffer pointers that have not been allocated. For instance

snprintf( buff, max, "%.*s", length, NULL + index. ) could catch the
invalid pointer (so long as index is small) before a segfault can occur and
if stdlib is not in debug mode then allow the segafault to occur, otherwise
return -1 and set errno to some relevant value

On Thu, 31 Jul 2025 at 16:36, Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> 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?
>
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* zxuiji <gb2985_at_[hidden]>
> *Gesendet:* Do 31.07.2025 17:21
> *Betreff:* Re: [std-proposals] Standardising 0xdeadbeef for pointers
> *An:* std-proposals_at_[hidden];
> *CC:* Sebastian Wittmeier <wittmeier_at_[hidden]>;
> That's why I'm saying having a definitely invalid range would be useful,
> take for example:
>
> inline bool isptrinvalid( void *addr ) { return (addr >=
> -MAX_INVALID_ADDRESS && addr <= MAX_INVALID_ADDRESS); }
> It doesn't need to be an inline since there's system specifics but just
> having that range would be a good enough for said libraries to rely on in
> older versions of c/c++
>
> On Thu, 31 Jul 2025 at 16:17, Sebastian Wittmeier via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
> One could define a possibly inlined standard function: Is pointer
> definitely invalid, which does not give a guarantee that it is valid, but
> possibly catches more than nullptr.
>
>
>
> No need to start with page sizes.
>
>
>
> The coverage of this function could be QoI and for simple systems, it
> could just return false (not definitely invalid) or just compare to nullptr.
>
> -----Ursprüngliche Nachricht-----
> *Von:* zxuiji via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Do 31.07.2025 17:09
> *Betreff:* Re: [std-proposals] Standardising 0xdeadbeef for pointers
> *An:* Thiago Macieira <thiago_at_[hidden]>;
> *CC:* zxuiji <gb2985_at_[hidden]>; std-proposals_at_[hidden];
> It's useful to know a standard range to apply. For example libraries like
> boost could detect if pointers passed to them are in said range and catch
> the problem before a segfault can happen. They can in turn exit the thread
> but not the whole app/game/etc.
>
> On Thu, 31 Jul 2025 at 16:05, Thiago Macieira <thiago_at_[hidden]> wrote:
>
> On Thursday, 31 July 2025 08:08:51 Pacific Daylight Time zxuiji wrote:
> > So we're designing for lala land where any and all silly systems exist
> are
> > we? Just define a minimum based on real world standards which as far as
> I'm
> > aware is 512 minimum which is reasonable enough for a `MIN_PAGE_SIZE 512`
> > macro and certainly reasonable for a `MAX_INVALID_ADDRESS ((void*)512)`
> > macro
>
> Why do we need to change anything? What's the motivation?
>
> We know that effectively the first and last pages are unavailable for any
> system. So if you need to do some pointer math and know they are invalid,
> you
> can.
>
> But why does the *standard* need that?
>
> --
> 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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>