Hacker News new | ask | show | jobs
by Arrath 1368 days ago
> "This is the first time we had to make sure the game is deterministic between ARM and x86. We should be fine, C++ is portable, right? Just don't use undefined behavior. Turns out we use quite a lot of undefined behavior..."

Hah

2 comments

This has been my experience dealing with portability and C++ as well. In theory, very portable. In practice, "portable" as long as you don't care about the details of how features work and didn't use any undefined behaviors that just happened to work in the first architecture but are implemented totally differently in the new architecture (and C++, of course, embraces undefined behavior instead of keeping the developer out of it).

Things as simple as "believing you know the byte-width of a primitive data type" are dangerous.

Would it occur had they used UBsan on debug builds?
No doubt. For starters, UBsan does not check for any invalid memory access.

In my C++ course, I require that the code runs correctly under 5 different compilers (GCC, LLVM Clang, Apple Clang, MSVC, Intel C++ Compiler Classic) on 3 OS (Ubuntu, Windows, macOS) in Release, Debug+Valgrind, Debug+Sanitizers modes, and students still get UB quite often.

Extra reading: http://evan.nemerson.com/2021/05/04/portability-is-reliabili... and discussion at https://news.ycombinator.com/item?id=27044419

Why even write C++ at that point? Wouldn’t changing over to Rust save you at least a couple of those steps?
Tooling, libraries, OS vendor support, IDEs, work force availability,...

Many of us write C and C++, because we have to, not because we want to.

Rust will eventually reach there, however many of us want to deliver a product, not build an ecosystem from scratch.

It won't find threading issues, or "implementation-defined behavior" (which isn't the same thing as undefined behavior).
For things that UBsan checks for, yes, but there's a ridiculous amount of things that are surprisingly UB in C(++).