3 ms·

But at the same time it is totally expected in C and C++ that range checking is the responsibility of the programmer, and most of those problems are trivial to

But at the same time it is totally expected in C and C++ that range checking is the responsibility of the programmer, and most of those problems are trivial to catch with Valgrind or ASAN. E.g. yes, it is a problem, yes, 70% of all CVEs are caused by memory corruption, but the problem is totally obvious and trivial to debug. It's basically part of the contract when deciding to use C or C++. Compared to such 'obvious' memory corruption problems caused by invalid pointers or missing range checks, obscure code generation issues caused by UB are much harder to identify and the behaviour may also change randomly between compiler versions - this is the actually scary thing about UB, and it's also a relatively "new" thing.

H8crilA 3y ago
The point is exactly that "it is totally expected", and it has caused massive losses over the decades. It has been abused for everything ranging from turning your friend's PC off, to ransomware, to state-on-state espionage and even causing nuclear incidents in Iran's enrichment facilities. The behavior is undefined.
- flohofwoe 3y ago
  Sheesh, the sky didn't fall, the world didn't end, and humanity survived. UB won't end the world. Relax.
  - H8crilA 3y ago
    Perhaps we're not in a discussion that's worth continuing, but I'm talking about programming language design. There are languages with UB, and there are languages without UB - and I think in 2024 the verdict is clear.
    - flohofwoe 3y ago
      Maybe from your point of view. But from elsewhere UB can be a useful tool because it allows wiggle room for compilers to support a wide range of platforms without sacrificing efficiency. It doesn't have to be as crazy as in modern C/C++ compilers, but some sane UB definitely makes sense (even Rust has that inside unsafe blocks). One could also argue that most UB in C/C++ should actually be IB, but that's a different discussion.
      - tialaramex 3y ago
        This "Wiggle room" would be at most implementation defined and in some cases just unspecified values, these probably aren't desirable but yes they're less dangerous than UB. Rust has UB if you don't obey the rules (Safe Rust doesn't because the rules are not your responsibility in Safe Rust, the unsafe superpowers allow you to do things the enforcement can't check but now all rules are your responsibility) but it's not somehow magically "more sane" than C++ it's ultimately lowering to the same LLVM IR that Clang uses. It's tolerable because you're only confronting the risk when you explicitly choose to do so. If you don't need to squeeze that last few drops of performance you can leave it. If you don't have the confidence, if your experts are too busy to review it, if you haven't had a proper night's sleep, you can write safe Rust today.
lolc 3y ago
> the problem is totally obvious and trivial to debug. We live in parallel universes that must have intersected in this thread.
- flohofwoe 3y ago
  Debugging tools got a lot better in the last two decades, memory corruption issues and leaks are by far not as scary anymore as in the 90s and early 2ks, for instance check out the realtime memory debugging panel in Visual Studio that's been there since VS2015. Also as mentioned at the top of the thread: compiler warnings, ASAN, UBSAN, TSAN and static analyzers are essential these days when writing C or C++ code. The only barrier is to actually know about and use those tools in the development workflow. Rust is still superior of course (for memory safety at least), because it actually prevents most of those issues in the first place, but it's not like the rest of the world has been twiddling thumbs in the meantime.
  - Leherenn 3y ago
    It certainly got better, but it's still not trivial. With the sanitizers, you need to have code that actually triggers the UB, coverage is not enough. If your UTF-8 parsing code UB only on some very specific input, then unless your tests or own environment happen to have this input, you'll be none the wiser. Fuzz testing helps, but it's not commonly used in my experience.

H8crilA 3y ago

The point is exactly that "it is totally expected", and it has caused massive losses over the decades. It has been abused for everything ranging from turning your friend's PC off, to ransomware, to state-on-state espionage and even causing nuclear incidents in Iran's enrichment facilities. The behavior is undefined.

flohofwoe 3y ago
Sheesh, the sky didn't fall, the world didn't end, and humanity survived. UB won't end the world. Relax.
- H8crilA 3y ago
  Perhaps we're not in a discussion that's worth continuing, but I'm talking about programming language design. There are languages with UB, and there are languages without UB - and I think in 2024 the verdict is clear.
  - flohofwoe 3y ago
    Maybe from your point of view. But from elsewhere UB can be a useful tool because it allows wiggle room for compilers to support a wide range of platforms without sacrificing efficiency. It doesn't have to be as crazy as in modern C/C++ compilers, but some sane UB definitely makes sense (even Rust has that inside unsafe blocks). One could also argue that most UB in C/C++ should actually be IB, but that's a different discussion.
    - tialaramex 3y ago
      This "Wiggle room" would be at most implementation defined and in some cases just unspecified values, these probably aren't desirable but yes they're less dangerous than UB. Rust has UB if you don't obey the rules (Safe Rust doesn't because the rules are not your responsibility in Safe Rust, the unsafe superpowers allow you to do things the enforcement can't check but now all rules are your responsibility) but it's not somehow magically "more sane" than C++ it's ultimately lowering to the same LLVM IR that Clang uses. It's tolerable because you're only confronting the risk when you explicitly choose to do so. If you don't need to squeeze that last few drops of performance you can leave it. If you don't have the confidence, if your experts are too busy to review it, if you haven't had a proper night's sleep, you can write safe Rust today.

lolc 3y ago

> the problem is totally obvious and trivial to debug. We live in parallel universes that must have intersected in this thread.

flohofwoe 3y ago
Debugging tools got a lot better in the last two decades, memory corruption issues and leaks are by far not as scary anymore as in the 90s and early 2ks, for instance check out the realtime memory debugging panel in Visual Studio that's been there since VS2015. Also as mentioned at the top of the thread: compiler warnings, ASAN, UBSAN, TSAN and static analyzers are essential these days when writing C or C++ code. The only barrier is to actually know about and use those tools in the development workflow. Rust is still superior of course (for memory safety at least), because it actually prevents most of those issues in the first place, but it's not like the rest of the world has been twiddling thumbs in the meantime.
- Leherenn 3y ago
  It certainly got better, but it's still not trivial. With the sanitizers, you need to have code that actually triggers the UB, coverage is not enough. If your UTF-8 parsing code UB only on some very specific input, then unless your tests or own environment happen to have this input, you'll be none the wiser. Fuzz testing helps, but it's not commonly used in my experience.