Chromium, OpenSSL, the Linux kernel, the Windows NT kernel, have all suffered from security vulnerabilities due to undefined behaviour. We can bet they will continue to suffer from such issues. It's not something you can avoid simply by being competent and careful.
edit: As lmm says, it's likely you have UB issues in your code you aren't aware of. That's not quite the same thing as having issues in your code due to not being a good enough language-lawyer. I've resolved some very subtle issues that found their ways into a 'serious' C++ codebase, and I didn't spend that long in the C++ world. In most languages those issues simply couldn't have happened in the first place.
> the more bugchecked and field tested the code is, the more obscure any bug that surface is?
Right. A battle-tested codebase only has subtle errors, as the obvious ones will all have been fixed. An immature codebase has subtle errors and more obvious ones.
> GCC compiles to alot of architectures. I have a hard time imagining any modern language compiling to all those platforms without quirks in practice.
Compiler bugs are a separate issue from undefined behaviour and surprising language subtleties. With mature compilers they're pretty rare, but they do happen.
JavaScript is a good example. There's no undefined behaviour in JavaScript. That's vitally important given that JavaScript engines have to be able to run untrusted code. If JavaScript code is able to cause undefined behaviour, that's a serious security issue in the engine. Such bugs do happen, of course, but they aren't all that common. Generally, JavaScript runs fine regardless of whether you're running on x86, AMD64, or AArch64. Same goes for Java.
(I admit I'm ignoring the possibility of a constrained/contained kind of undefined behaviour where the JavaScript context might see things go haywire but the process containing the JavaScript environment is unaffected.)
How do you know? One of the reasons they're so insidious is that code that hits them tends to work fine until it gets compiled with a newer version of the compiler. E.g. signed integer overflow did exactly what you expect in most compilers until fairly recently.
> E.g. signed integer overflow did exactly what you expect in most compilers until fairly recently.
How recently? Both gcc 4.1.2 (2007) and clang 3.0.0 (2011) optimizes `x+1 > x` to true for a signed int `x` on -O1. And it probably goes way back, these are just the oldest compilers I found on godbolt.
Ah, point taken, but that's within the bounds of what many people expect; propagating the fact that the overflow is "impossible" to rearrange earlier control flow is more surprising and more recent.
> Ah, point taken, but that's within the bounds of what many people expect;
The thing is it's very hard to draw the line once you go that route. Different people expect different things from undefined behavior. The best thing is to not expect anything sane. And if you are unhappy about certain undefined behaviors in the standard then it's better to push the standard to define more behavior. Certain unnecessary undefined behaviors get resolved with newer standards, although I would expect significant pushback on defining the behavior signed integer overflow.
I understand there's a good chance the next standard will specify that signed integer overflow results in an unspecified value, which would match the behaviour of older compilers and what (IME) most programmers tend to expect.
Ye that is true. C compilers got some strange gotchas that you need to memorize but my main point is that those problems atleast to my projects are miniscule compared to off by one out of bound array access or dereferencing null pointers.
I agree with you here, but even these two categories of runtime errors are much more painful in C/C++ than in most other languages.
As I mentioned elsewhere in the thread, you can ask gcc to trap if your code is about to dereference NULL, but the compiler can't easily detect all instances of out-of-bounds array access, due to the way arrays and pointers work in C. I believe Valgrind can help detect out-of-bounds errors at runtime, but in most languages you don't need a sledgehammer like Valgrind to find these common errors.
