3 ms·

Note that in most scenarios compiler do not "recognize UB" and then don't tell you about it. Instead, they do not know whether there will be UB or not at run-ti

by uecker 2y ago

Note that in most scenarios compiler do not "recognize UB" and then don't tell you about it. Instead, they do not know whether there will be UB or not at run-time and simply assume that you know what you are doing. I also like to point out that not all modern compilers behave the same way. GCC will (in the case it is clear there will be a null pointer dereference) compile it into a trap, while clang will cause chaos: https://godbolt.org/z/M158Gvnc4 https://godbolt.org/z/M158Gvnc4 Both have sanitizers to detect this scenario.

rstuart4133 2y ago
> Note that in most scenarios compiler do not "recognize UB" and then don't tell you about it. Instead, they do not know whether there will be UB or not at run-time and simply assume that you know what you are doing. The point is the old K&R era compilers did that 100% of the time, whereas the current crop uses UB as an excuse to generate some random behaviour some percentage of the time. Programmers can't tell you when that happens because it varies wildly with compilers, versions of compilers and flags passed. Perhaps you are right in saying it's "most scenarios" - but unless you are a compiler writer I'm not sure who you would know, and even then it only applies to the compiler you are familiar with.