> 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

But handling a SIGSEGFAULT is already a mechanic to detect (some) cases of acces through invalid pointer value and it works from all userspace code (library or not). The conservative and general approach to handle this is to fail fast and stop execution : if the upcoming code relies on that pointer indirection to keep executing in a consistent way (which is the common case), then not stopping execution (and using some other value if the pointer was read) will lead to data corruption and misbehavior in upcoming code that relied on the invalid indirection. In other words, the bug leads to deterioration of the semantics of the program : at some point it will end up with misbehaving.

If you need to detect fatal signal without crashing the man executable loop, you should spawn work in forked subprocess.



On July 31, 2025 11:56:26 a.m. EDT, zxuiji via Std-Proposals <std-proposals_at_[hidden]> wrote:
>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
>>