5 ms·

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 t

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.
- 112233 2y ago
  I assume from your comment that you know how to write code that does not have such bugs. Could you please share? In particular: how do you write a library that guaranteed will not have integer overflow on any existing or future architectures and compilers?
  - steveklabnik 2y ago
    > how do you write a library that guaranteed will not have integer overflow on any existing or future architectures and compilers? By following the behavior in the standard, and not trying to imagine how the standard is implemented. For example, C23 includes https://en.cppreference.com/w/c/header/stdckdint https://en.cppreference.com/w/c/header/stdckdint, which you can safely use to check for overflows. It's also in C++23. If you're not on the latest standards, there are techniques to do so as well, these macros codify existing practice: https://stackoverflow.com/questions/199333/how-do-i-detect-unsigned-integer-overflow https://stackoverflow.com/questions/199333/how-do-i-detect-u...
    - 112233 2y ago
      Thank you for these references. It is how you say, and, for c++ would involve handling 16 bit "int", char larger than 8 bits and in the case of pre-20 compilers you cannot even assume two's compliment. I am sure such correct code can be written, but expecting everyone to play along with standard and ignore that 100% of existing compilers have much saner behaviour, might be very difficult.
      - steveklabnik 2y ago
        I’m not sure what “100% of compilers have much saner behavior” means. I do agree that avoiding UB is difficult.
  - bluGill 2y ago
    Same way any other language. That Rust defines what happens doesn't change the fact that it is a bug when it happens (in most cases). Which is to say not nearly as well as I would like.

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.
112233 2y ago
I assume from your comment that you know how to write code that does not have such bugs. Could you please share? In particular: how do you write a library that guaranteed will not have integer overflow on any existing or future architectures and compilers?
- steveklabnik 2y ago
  > how do you write a library that guaranteed will not have integer overflow on any existing or future architectures and compilers? By following the behavior in the standard, and not trying to imagine how the standard is implemented. For example, C23 includes https://en.cppreference.com/w/c/header/stdckdint https://en.cppreference.com/w/c/header/stdckdint, which you can safely use to check for overflows. It's also in C++23. If you're not on the latest standards, there are techniques to do so as well, these macros codify existing practice: https://stackoverflow.com/questions/199333/how-do-i-detect-unsigned-integer-overflow https://stackoverflow.com/questions/199333/how-do-i-detect-u...
  - 112233 2y ago
    Thank you for these references. It is how you say, and, for c++ would involve handling 16 bit "int", char larger than 8 bits and in the case of pre-20 compilers you cannot even assume two's compliment. I am sure such correct code can be written, but expecting everyone to play along with standard and ignore that 100% of existing compilers have much saner behaviour, might be very difficult.
    - steveklabnik 2y ago
      I’m not sure what “100% of compilers have much saner behavior” means. I do agree that avoiding UB is difficult.
- bluGill 2y ago
  Same way any other language. That Rust defines what happens doesn't change the fact that it is a bug when it happens (in most cases). Which is to say not nearly as well as I would like.