C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Standardising 0xdeadbeef for pointers

From: Julien Villemure-Fréchette <julien.villemure_at_[hidden]>
Date: Fri, 01 Aug 2025 11:29:12 -0400
> 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.

If the said thread is necessary for the main app to make any progress (which is usual), then absorbing any fatal signal in that thread won't help the app in making progress. The fact that the segfaulting code occurs in a separate thread or not is not a relevant in the choice of which execution agent should be stopped when UB/bug/fatal signal is observed (should it be observed). Whether a program spawns any thread to perform its task is likely an implementation detail, so any action upon receipt of a fatal signal, or observed UB like Contracts violation should definitely affect the hole process.

There is one proper way to isolate your main application loop from potential bugs and fatal signals or corruption of data in the lower level servicing code: instead of creating threads, fork a new process and delegate the complex work there. Any crash on worker process affects only that process and will report its signal to the main process through a wait() function.



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

Received on 2025-08-01 15:29:22