> This is why if you're currently writing C or C++, please, please look into Rust.

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.

Personally, I am in wait and see mode on Rust. Without better generics support (aka template <size_t> or similar) and a number of other things, it still doesn't meet my bar for writing fast generic code, and who knows how complex it will be at that point? I say the jury is still out.

> 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.

> 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.

> 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.

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.

It's not like you stumble over UB in your daily work in C/C++, you know it exists, you know which areas to avoid, you compile and test on the 3 "big" compilers (gcc, clang, cl.exe). On clang, test with UBSan enabled.

UB isn't "crazyness" it's just a detail to be aware of.

A compiled binary that worked correctly won't suddenly run into undefined behaviour, that can only happen if you upgrade compiler versions or change compilation flags. But this only happens while the application is still actively developed and tested.

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.

Of course, and that's exactly where Rust makes sense. Few pieces of software are as safety-critical and complex as a browser though, that's why I'm not a fan of the general "UB scaremongering" ;)

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.

> 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 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.

> 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.

> This is why if you're currently writing C or C++, please, please look into Rust.

But please, please also look into its platform support table[1], too. If you're the slightest bit opposed to the Windows/macOS/Linux hegemony, you may want to reconsider Rust.

[1] https://forge.rust-lang.org/platform-support.html

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.

Are there any large programs like BIND written in Rust? If so, what is their actual security record?

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.

There is a whole OS, good enough?

If you mean Redox, that is hardly a production OS (yet).

People don't have infinite time and only search for security issues in software that's actually in use.

Which is one of the reasons that C/C++ appear more often in CVEs.

The OP asked for an example of a large program like BIND, I gave him/her an OS, which naturally also contains something like BIND, but apparently we now move the goal posts for how much users it has.

I love how people hand have the fact that even projects like the Linux kernel, with their stringent processes aren't able to avoid CVEs, to the point it became the major focus of Linux Kernel Security Summit 2018.

Yet we all know that only newbies do major errors in C. /s

Depends on popularity and use.

The question was about an example for a large program like BIND.

Which one?

"Undefined behavior" in C++ just means stuff that's either CPU-specific or compiler-specific.

Rust has no undefined behavior because it only supports one CPU and has only one compiler implementation.

When Rust supports a dozen architectures and has three different compiler implementations then Rust will be just as full of UB as C++. Except with the added "bonus" of all the UB being brand-new and unspecified, unlike the well-known portability pitfalls of C++.

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.

> When Rust supports a dozen architectures

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

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.

UB is an implementation issue, not a language issue. UB is a fact of life that cannot be removed by overspecifying a language -- if your language spec has too much implementation-specific stuff in it, then compiler writers will simply ignore it. Many such examples. The best you can do is to document the implementation-specific stuff extensively.

Also, implementation-specific details aren't always about maximizing performance. Compilers implement languages slightly differently because of architecture and OS differences and because it's easier that way for the people writing compilers.

UB is not implementation specific at all, the ISO documentation is quite clear about which is which.

Other systems languages manage to do it quite well.

It was really a shame that Bell Labs gave UNIX away for a symbolic price during 10 years before being allowed to actually sell it.

We wouldn't be having this kind of C related talks.

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

That is not true. Rust works on multiple architectures.

There's a massive chasm between "works on" and "supports".

That doesn't seem relevant -- Rust works on and supports multiple architectures. And there's plenty of UB in unsafe code.