4 ms·

I think I'm misunderstanding something. The post sounds like UB has already been mostly eliminated from recent versions of C++. But to my knowledge even somethi

by mafuy 2y ago

I think I'm misunderstanding something. The post sounds like UB has already been mostly eliminated from recent versions of C++. But to my knowledge even something simple as `INT_MAX + 1` is still UB. Is that false?

saagarjha 2y ago
No, it’s true. None of these efforts significantly change the prevalence of UB in C++.
nmeofthestate 2y ago
I think you are misunderstanding the post - it specifically says that there's "a metric ton of work" to be done to address UB, not that it's mostly a solved problem.
bluGill 2y ago
Stop using `INT_MAX + 1` as an example! It is the worst possible example you can give (though easy to understand). Such code is essentially never a memory safety issue and not to what most people worry about UB. In the vast majority of cases it doesn't matter what `INT_MAX + 1` does you code it wrong. Sure there are a few encryption cases where it is fine, but the vast majority of cases your code as a bug no matter what the result it. If the variable netWorth is at INT_MAX there is no value of adding 1 that is correct. If the variable employeeId is at INT_MAX all values of adding 1 are going to collide with an existing employee. Meanwhile if you define INT_MAX+1 you force the compiler to add checks for overflow INT_MAX in addition operations even though most of the time you won't overflow and thus have needlessly slowed down the code. UB causes real problems in the real world, but INT_MAX+1 is not one of those places where it causes problems.
- AlotOfReading 2y ago
  INT_MAX+1 is actually a great example of UB because it demonstrates how UB is a problem even if there's a completely reasonable runtime behavior. One of the big reasons UB is problematic is that it invalidates the semantic guarantees the standard makes about all your other code. That signed integer overflow completely invalidates any sort of formal proofs or error handling you might otherwise have.
- Maxatar 2y ago
  This is a very worrisome perspective about undefined behavior. It suggests that the issue with undefined behavior is that there is a bug in your code and it's the bug that is the problem. But that's not (entirely) the case, the issue with undefined behavior is that compilers exploit it in ways that propagate this behavior in an entirely unbounded fashion that can result in bugs not only at the very moment that the undefined behavior happens, but even before it, ie. the infamous time travelling undefined behavior [1]. Getting rid of undefined behavior will not get rid of bugs, and no one thinks that memory safe languages somehow are bug free and certainly C++ code will not be bug free even if undefined behavior is replaced with runtime checks. What eliminating undefined behavior does is it places predictable boundaries on both the region of memory and the region of time that the bug can affect. [1] https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=633 https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=63...
  - bluGill 2y ago
    The article already says we need to get rid of (or at least greatly restrict) time travel optimizations. Your code has a bug if addition overflows and there is no point in defining how it works.
    - pjmlp 2y ago
      The security problem is how "addition overflows", or "this will never overflow", have a side effect on security related checks that get removed. Naturally whatever happens to a CPU register in isolation doesn't turn right away into a security issue.
    - Maxatar 2y ago
      I don't see where the article says that it will get rid of that. The article simple says: >UB optimizations also just create mysterious ordinary bugs, such as ... “time travel” optimizations that change code that precedes the point where the UB can happen. >Less of all those things, please. I don't think someone saying "less of those things please" is the same as saying "we need to get rid of this or greatly restrict it". Also once again, I really find problematic the idea that it's the existence of a bug itself in code that is the main issue. That is a standard that absolutely no language or technology can ever eliminate. The goal of any safety related proposal is not to make it impossible to write bugs, but that the consequences of those bugs are constrained in both space and time.

by mafuy 2y ago

saagarjha 2y ago

No, it’s true. None of these efforts significantly change the prevalence of UB in C++.

nmeofthestate 2y ago

I think you are misunderstanding the post - it specifically says that there's "a metric ton of work" to be done to address UB, not that it's mostly a solved problem.

bluGill 2y ago

Stop using `INT_MAX + 1` as an example! It is the worst possible example you can give (though easy to understand). Such code is essentially never a memory safety issue and not to what most people worry about UB. In the vast majority of cases it doesn't matter what `INT_MAX + 1` does you code it wrong. Sure there are a few encryption cases where it is fine, but the vast majority of cases your code as a bug no matter what the result it. If the variable netWorth is at INT_MAX there is no value of adding 1 that is correct. If the variable employeeId is at INT_MAX all values of adding 1 are going to collide with an existing employee. Meanwhile if you define INT_MAX+1 you force the compiler to add checks for overflow INT_MAX in addition operations even though most of the time you won't overflow and thus have needlessly slowed down the code. UB causes real problems in the real world, but INT_MAX+1 is not one of those places where it causes problems.

AlotOfReading 2y ago
INT_MAX+1 is actually a great example of UB because it demonstrates how UB is a problem even if there's a completely reasonable runtime behavior. One of the big reasons UB is problematic is that it invalidates the semantic guarantees the standard makes about all your other code. That signed integer overflow completely invalidates any sort of formal proofs or error handling you might otherwise have.
Maxatar 2y ago
This is a very worrisome perspective about undefined behavior. It suggests that the issue with undefined behavior is that there is a bug in your code and it's the bug that is the problem. But that's not (entirely) the case, the issue with undefined behavior is that compilers exploit it in ways that propagate this behavior in an entirely unbounded fashion that can result in bugs not only at the very moment that the undefined behavior happens, but even before it, ie. the infamous time travelling undefined behavior [1]. Getting rid of undefined behavior will not get rid of bugs, and no one thinks that memory safe languages somehow are bug free and certainly C++ code will not be bug free even if undefined behavior is replaced with runtime checks. What eliminating undefined behavior does is it places predictable boundaries on both the region of memory and the region of time that the bug can affect. [1] https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=633 https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=63...
- bluGill 2y ago
  The article already says we need to get rid of (or at least greatly restrict) time travel optimizations. Your code has a bug if addition overflows and there is no point in defining how it works.
  - pjmlp 2y ago
    The security problem is how "addition overflows", or "this will never overflow", have a side effect on security related checks that get removed. Naturally whatever happens to a CPU register in isolation doesn't turn right away into a security issue.
  - Maxatar 2y ago
    I don't see where the article says that it will get rid of that. The article simple says: >UB optimizations also just create mysterious ordinary bugs, such as ... “time travel” optimizations that change code that precedes the point where the UB can happen. >Less of all those things, please. I don't think someone saying "less of those things please" is the same as saying "we need to get rid of this or greatly restrict it". Also once again, I really find problematic the idea that it's the existence of a bug itself in code that is the main issue. That is a standard that absolutely no language or technology can ever eliminate. The goal of any safety related proposal is not to make it impossible to write bugs, but that the consequences of those bugs are constrained in both space and time.