A Guide to Undefined Behavior in C and C++ (2010)

This isn't necessarily true. Many compiled languages these days have a strong specification that guarantees a lack of undefined behavior for the vast majority of code, yet remain relatively performant–think Swift, Rust, and the like.

Being dog slow is very much dependent on the use case.

Yes it will be slower than taking every shortcut in the name of performance.

What really matters is, does the execution speed and memory footprint meat the requirements?

If the user is happy to get their data in 100ms, with a requirement of 300ms max, getting it in 10ms is hardly an advantage.

> In this case, the UB is due to the compiler's ability to reorder statements.

No, the undefined behavior arises because dividing by zero is undefined. Languages wishing avoiding this particular bug can make division by zero defined to trap or have some sort of guaranteed behavior, after which the compiler is required to not reorder those statements. In this case reordering the instructions is legal because having undefined behavior in your program makes literally anything the compiler does legal.

My point is that it is humanly impossible to write a bug-free program. In C and C++, bugs usually manifest themselves in UB.

To make matters worse, compilers, ever searching for diminishing returns on performance improvements, have been steadily making the CONSEQUENCES of UB worse, to the point that even debugging is getting harder and harder. These languages are unique in their growing user hostility.

I was always able to write fast code in languages like Object Pascal and Ada, while being safe from C and C++ UB cargo cult.

> The premise of languages like C and C++ is that the airgap between the language's abstract execution and memory model and the hardware's is thin to non-existent.

Which is not really the case for processors from the last 20+ years.

> In this case, the UB is due to the compiler's ability to reorder statements. This is such a fundamental optimization that I can't imagine you're really suggesting that a language without this optimization capability is a "problem." Rearranging instructions is critical for pretty much any superscalar processor (which all the major ones are), and I hate to imagine the hell I'd be in if I had to figure out the optimal load/store ordering myself.

UB is not necessary for that though. E.g. define that integer division by zero leads to the process receiving a terminal signal. That could be implemented just as efficiently (trapping on division by zero free at the hardware level in modern processors, the C standard gives broad freedom for signals to be received asynchronously so instructions could still be reordered), but would close the door to silent memory corruption and arbitrary code execution: unless the programmer has explicitly defined how the signal is handled, their program is noisily terminated.

> "Undefined behavior" doesn't mean "buggy". It simply means stuff that's CPU-specific or compiler-specific.

Yes, it does. The behavior you are describing is "implementation specific", and it is ok to have this in your program provided you know what your implementation will do. It is illegal to have any undefined behavior in a well-formed C/C++ program.

UB is a way to better optimize code by (silently) offloading a burden of correctness proof to a programmer. Rust prefers to be more explicit about it. Const generics will surely not change that.

> Ugh if you read the article, you would know that the UB described here is the same in Rust. There is this massive group think about which languages are safe and/or fast, and whenever an article like this comes up, invariably someone says "Rust!" without really looking at the problem itself.

Rust does have vocal proponents, but I don't see how "the UB described here is the same in Rust". Rust should trap consistently when dividing by zero.

> Ugh if you read the article, you would know that the UB described here is the same in Rust.

Rust doesn't have a formal memory model yet, but it's already known that UB in Rust is quite restricted:

https://doc.rust-lang.org/nomicon/what-unsafe-does.html

Most importantly, UB in Rust should only arise if you're writing unsafe code (barring compiler bugs). Typically, most Rust code is safe. This is a huge win.

> the UB described here is the same in Rust

I don't think this is correct. Dividing by zero in Rust produces a panic, and panics are observable side effects that may not be reordered with other side effects. This is sometimes annoying, because it can prevent the compiler from eliminating bounds checks in some cases, but it avoids the problems mentioned in this article.

> Ugh if you read the article, you would know that the UB described here is the same in Rust.

Ugh, if you took the time to learn Rust before criticizing it, you'd know that Rust only allows undefined behavior in unsafe blocks.

> Without better generics support

So you have no idea what generics are. Templates aren't generics, they're fancy code generators expanded at compile time, which means they're incredibly loosely typed and allow you to do things like have scalar parameters like size_t n (because they're basically macros). C++ templates are essentially a form of duck typing that has led to an increased need for specification, hence concepts in C++20.

Rust's parametric polymorphism and type classes (aka generics) follows in the ML and Haskell tradition in that the type checking is like a constraint program that is run at compile time. When a generic item is invoked, the specification of that type is immediately checked for consistency at the call site, otherwise the typechecking fails.

> Rust has no undefined behavior because it only supports one CPU ...

That is not true. Rust works on multiple architectures.

I am happily running Rust generated code on my ARM microcontrollers. Rust uses LLVM for code generation and can support any architecture which LLVM supports.

There are plenty of system languages with a very tiny percentage of UB vs all the languages that allow for copy-paste of C code.

Because they prefer to loose a couple of ms to paying the price of the ultimate performance might bring.

Like in real life you can speed at 300 KMH with a 1200cc motorbike, or doing it a car with reinforced structure wearing seatbelts and airbags.

Even with diminished chances of survival, I rather be in the car.

> When Rust supports a dozen architectures

"Rust now available on 14 Debian architectures" https://lists.debian.org/debian-devel-announce/2018/11/msg00...

There is a whole OS, good enough?

Several bits of Firefox are written in Rust now. Looking through the bug reports, there has yet to be any CVE in any of the Rust-rewritten components.

TrustDNS is one in that space. We won't know for a while what actual, security record is. We do have some evidence from fuzzing where it led to panics vs worse effects in C. I think an objective test would compare effects of fuzzing Rust and C libraries to see how often Rust just panicked. The study should use different types of libraries that use the language in different ways. If Rust's claims are true, most problems will involve 3rd-party libraries that aren't Rust, unsafe Rust, and/or compiler errors that break safety. People doing the study could just grab popular C apps vs similar stuff in Rust on Github that's actually maintained. Also, look at amateurish and unmaintained stuff to see if those still have minimal vulnerabilities.

That's how I'd do it anyway.

That presumes that your testing process will find the input that actually triggers the UB in your program before the release.

The CVE history of the major browser vendors indicate that this is currently an unsolved problem for their large C++ applications.

> A compiled binary that worked correctly won't suddenly run into undefined behaviour, that can only happen if you upgrade compiler versions...

Upgrading the compiler version and causing undefined behavior sounds pretty sudden. Here's my favorite story along those lines: http://pzemtsov.github.io/2016/11/06/bug-story-alignment-on-...

> It's not like you stumble over UB in your daily work in C/C++...

I don't know. I often help colleagues out with things like preprocessor nonsense and violations of the One Definition Rule.

A lot of it has to do with difficult build and packaging tools. Actually standardizing a module system will be an important step in the right direction.

Full-time C++ game dev of ~5 years here. I absolutely run into UB issues at least once a month, sometimes as often as a couple times in a week. I doubt our codebase is of below average quality either. UBsan is a godsend here... without it, this stuff was truly hell to debug.

It isn't just UB. It's ADL, ODR, templates, multiple inheritance, etc. The de facto compatibility with C and its own backwards compatibility are also both curses on C++. C++ also blew their complexity budget in a lot of questionable ways that just makes it hard to keep C++ code maintainable. When things become unmaintainable, they become buggy.

What exactly are you saying? Rust can be built with zero os/kernel dependencies at all. Case in point, people have written entire operating systems on bare metal in rust.

I agree, the problem is ensuring everyone at the company and third party dependencies, many of which available as binary libs only, do actually use those modern C++ constructs.

Interesting project; are you aware of any actual users?

Meanwhile, in the real world, C++ programmers typically use operator+(int,int) with UB on overflow because it's conveniently built into the language.

The problem with C++ isn't that doing the right thing is impossible, it's that doing the wrong thing is the default, with no dependencies and no syntactic overhead.