> To not giving up portability all compilers would have to do what you propose. Not in a lot of cases. Eg, let's suppose that GCC defines a NULL pointer derefe

> To not giving up portability all compilers would have to do what you propose. Not in a lot of cases. Eg, let's suppose that GCC defines a NULL pointer dereference to act exactly like a normal one. That is, the compiler dereferences the pointer, and whatever the CPU/OS says is going to happen when you read from 0x0, happens. Meanwhile, Clang continues with behaviors that can say lead to a function being entirely replaced with "return true". There's no problem whatsoever with this. You're still not supposed to dereference null pointers. It's just that on GCC in particular you get a predictable error. And being an error you can't really rely on it -- your program still crashes and crashes are still undesirable, and therefore you will fix whatever leads to that outcome. And on Clang maybe you don't crash but the program doesn't do what you expect it to, which is still a bug to be fixed. You have a bug in both versions which manifests in different ways (but that is fine, because UB says anything goes so there's no requirement whatsoever for both compilers to have the program break identically), but it's the same bug that needs the same fix. After the bug fix, your GCC compiled version doesn't crash and runs correctly, and your Clang compiled version doesn't crash and runs correctly. The behavior in the end is identical.