Date: Sat, 26 Sep 2026 08:41:34 +0200
> On Sep 25, 2026, at 5:10 PM, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Where the ISO C++ Standard says that a particular thing results
> in undefined behaviour, is it okay for a particular compiler to say
> that the behaviour is well-defined and that the entire program must
> continue to function as normal?
You are right that the standard does not say that. However, I believe there is no compiler out there that shows well-defined behavior. Sometimes the compiler detects UB and uses it to its “advantage”. It might depend on the optimization level. And in the next version of the compiler someone rearranges the optimization steps or new ones are added and the behavior changes once more. In order to make UB well-defined in a specific compiler (and not just one compiler version) great care would need to be taken. And once UB is well-defined programmers will start relying on it. It is not a good idea to rely on well-defined outcome of specific UB on a specific compiler.
C++ is also about speed. The only way of throwing an exception on a null dereference is to check every single dereference. Branches are potentially expensive on all CPUs. Just don’t do this. A library solution is much better! Take something like gsl::not_null, for example. Write your own types that check for nullptr on every dereference and throws an exception. Use raw pointer on the hot paths. Don’t overload operator+ to avoid pointer arithmetic or also check for nullptr. Write another class for non-null parameters that checks for non-null in their constructors (and deletes its copy and move constructors!). No compiler changes necessary! And it completely avoids UB in the first place! And the programmer decides what he wants where. Maybe you could also have some coding guidelines automatically checking for this. Only disadvantage is that the std math functions don’t have these checks by default (so, write some wrappers).
>
> Where the ISO C++ Standard says that a particular thing results
> in undefined behaviour, is it okay for a particular compiler to say
> that the behaviour is well-defined and that the entire program must
> continue to function as normal?
You are right that the standard does not say that. However, I believe there is no compiler out there that shows well-defined behavior. Sometimes the compiler detects UB and uses it to its “advantage”. It might depend on the optimization level. And in the next version of the compiler someone rearranges the optimization steps or new ones are added and the behavior changes once more. In order to make UB well-defined in a specific compiler (and not just one compiler version) great care would need to be taken. And once UB is well-defined programmers will start relying on it. It is not a good idea to rely on well-defined outcome of specific UB on a specific compiler.
C++ is also about speed. The only way of throwing an exception on a null dereference is to check every single dereference. Branches are potentially expensive on all CPUs. Just don’t do this. A library solution is much better! Take something like gsl::not_null, for example. Write your own types that check for nullptr on every dereference and throws an exception. Use raw pointer on the hot paths. Don’t overload operator+ to avoid pointer arithmetic or also check for nullptr. Write another class for non-null parameters that checks for non-null in their constructors (and deletes its copy and move constructors!). No compiler changes necessary! And it completely avoids UB in the first place! And the programmer decides what he wants where. Maybe you could also have some coding guidelines automatically checking for this. Only disadvantage is that the std math functions don’t have these checks by default (so, write some wrappers).
Received on 2026-09-26 06:41:47