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] <mailto: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] <mailto: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] <mailto:thiago_at_[hidden]> >; CC:zxuiji <gb2985_at_[hidden] <mailto:gb2985_at_[hidden]> >; std-proposals_at_[hidden] <mailto: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] <mailto: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 <http://macieira.info> - thiago (AT) kde.org <http://kde.org>   Principal Engineer - Intel Platform & System Engineering -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals