> On Feb 18, 2025, at 8:36 PM, Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Hi Oliver,
> in theory, one could either redefine pointer arithmetics and put a check for 0 there or additionally also redefine nullptr to have certain bits set or contain an additional bool.
> I think that is allowed by the standard (but worsens performance).

The problem here is that is that pointer arithmetic is UB once the arithmetic exceeds the bounds of the object (in the memory sense, not individual instance of some type sense) - e.g. a hypothetical

Int buffer1[10];
Int buffer2[10];

Even if you *know* these are allocated consecutively in memory it is UB to try to interact with buffer2 with (buffer1+10) - I _think_ this applies even if they are consecutive members in a struct. This problem comes up with null dereferencing as by definition `nullptr+x` is always going to be either null is x is 0, or a different object and so UB.

So as much as I want null dereferences to be EB it is hard to see how they can be without necessarily requiring explicit nullptr checks - at least for cases where the compiler is unable to leverage target defined semantics (e.g there are targets where large chunks of the top and/or bottom of the address space are never able to be mapped, so in principle if a compiler can prove that the requested offset would be within the unmapped range, and is definitely going to be derefenced then it could elide the explicit null pointer check, but that is just a target specific optimization and is not available in the general case).

—Oliver

>
>
> -----Ursprüngliche Nachricht-----
> Von: Oliver Hunt via Std-Proposals <std-proposals_at_[hidden]>
> Gesendet: Di 18.02.2025 23:10
> Betreff: Re: [std-proposals] try else syntax for validity check
> An: std-proposals_at_[hidden];
> CC: Oliver Hunt <oliver_at_[hidden]>;
>
>
> > On Feb 18, 2025, at 11:53 AM, Jennifier Burnett via Std-Proposals <std-proposals_at_[hidden]> wrote:
> >
> > Actually the capability of detecting nullptr dereferences (or any invalid memory access in general) is built into pretty much all hardware nowadays. Detecting ALL nullptr references and throwing an exception would be entirely free on most machines (and in fact this is what the android java runtime does, unless they've changed it).
>
> Producing specified behavior for a null dereference is not simply a matter of specifying the behavior of `*ptr` when ptr == nullptr, it requires specifying the behavior of `nullptr+offset`
>
> e.g.
>
> ptr[x] = 0
>
> If `ptr` is null, but `x` is large enough then `ptr[x]` may be a valid address, so the only way an implementation can produce a specified outcome to the null dereference is by requiring a null check on `ptr` prior to the actual load.
>
> I assume this latter case is why dereferencing null is UB - the trivial case of `*nullptr` is easily specifiable as EB, but once there’s a runtime offset you can’t practically define a result without requiring a null check on the base address.
>
> —Oliver
>
> --
> 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