> On Jul 25, 2025, at 3:19 PM, Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> I don't know about you, but intentionally segfaulting is not something I want in my application.

It is the safe response to invalid program state however - if you have a state error your options are

(1) Handle it yourself - e.g. don’t consider it a state error
(2) Terminate - e.g. once you’ve reached this invalid state you can no longer do anything because you don’t know what else is in an invalid state
(3) Continue executing - e.g. hope that this invalid state is not the result of an attacker exploiting (or attempting to) your code base

In all code I work on (1) and (2) are the only choices considered valid - even in the kernel: if you’ve reached a state that is sufficiently unexpected that you don’t handle it a panic is preferable to continuing. Obviously the goal is to have no cases like that, but a panic is absolutely preferred to running into random execution land.

>
> And having a discussion on a feature that requires your application to be ill formed is a waste of everyone's time.

Agreed

>
> A pointer is either null, valid, or not null but invalid (if used it's a bug).
> What need is there for a 4th state that is invalid, not null but another very specific value? When in all honesty null is already a good indicator that a pointer is invalid?

Yup - we already have enough difficulty reasoning about correctness with the existing set, how does adding more help?

—Oliver