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).   -----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] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals