4 ms·
Undefined behavior isn't a threat; it's a promise. That came out wrong. What I mean is that it's not a threat from the standard that its buddy the compiler wil
by GrantMoyer 2y ago
Undefined behavior isn't a threat; it's a promise.
That came out wrong. What I mean is that it's not a threat from the standard that its buddy the compiler will ruin your computer, your day, and your life. Instead, it's a promise from the programmer to the compiler that the programmer won't perform some operations.
Since the programmer promised not to do some things, the compiler assumes those things aren't done while reasoning about the code, but if it turns out one of those things was done, the compiler's whole chain of reasoning is potentially invalid. So the compiler's options are to trust the programmer, and make the assumptions, or to instead treat the programmer as a dirty liar, and not make any of the assumptions while expending much effort considering all the subtle ways the programmer could try to trick it. Actually, there's a third option, trust but verify, where the compiler trusts the programmer to make a best effort, but verifies the assumptions when convenient. Unfortunately, it's not often convenient to verify in C or C++, but broadly compilers are getting better at it over time.
- pif 2y agoVery well put! I'll just add that the third option is usually not considered viable because the main point of using C/C++ is for performance, thus people writing code want their compiler to optimize it as much as possible.
- int_19h 2y agoIn practice, the people pushing the most for UB being a "license to kill" tend to be compiler implementors though, not their users.
- GrantMoyer 2y agoI don't think compilers consider undefined behavior a license to kill; I think the problem is genuinely hard. The priciple of explosion[1] tells us that any wrong assumption, even the most innocuous looking, can lead to an unboundedly wrong conclusion. The more complex your graph of logical deductions, the worse the problem gets (and good optimizations require a lot of complex logic). It may be possible to limit the bad effects of faulty assumptions by being very careful about how deductions propogate from unreliable assumptions. However it's certainly not easy, especially without throwing out all optimizations that interact with a potentially undefined operation. It is possible to design a languge such that a compiler doesn't need to make assumptions to perform optimizations, if programs are required to give enough information to compilers that they can statically prove properties they need to perform optimizations. But C and C++ are not designed that way, and it can't easily be retrofitted on top of them. [1]: https://en.wikipedia.org/wiki/Principle_of_explosion https://en.wikipedia.org/wiki/Principle_of_explosion
- gavinhoward 2y agoOT, but did you get the "license to kill" phrase from me (https://gavinhoward.com/2023/08/the-scourge-of-00ub/ https://gavinhoward.com/2023/08/the-scourge-of-00ub/) or someone else? I ask because when I wrote that post, I couldn't remember if I had heard the term before. In other words, I am not sure if I copied someone else or not, and if I did, I want to add attribution.
- int_19h 2y agoI'm pretty sure I posted that comment after reading your post.