[foxfluff]

> However, there may still be a number of corner cases of the language like undefined behaviors. This is why people frequently fall into C's traps.

I don't think that's true; the UB that is relevant for day-to-day programming is easily learned.

It's just that a sucker is born every minute and there's always someone who's been taught that C is a high level assembler. Now and then someone slips a piece of code that assumes as much in a project and disproportionately big noise is made about it.

Most UB-related bugs in C code are not there because the author didn't know it's UB, but because they simply coded it wrong. People fall into simple buffer overflows, double frees, etcetra all the time and no-one thought it's ok to overflow a buffer.

[jstimpfle]

Right. All this buzz about UB is a bit much. Sure, it's not great to have to assume that something breaks when you upgrade your compiler when the compiler authors made a change to exploit some UB that I didn't know of.

On the other hand, I'm quite confident that I don't have much UB in my code (as running sanitizers from time to time confirms). And miraculously, I've never ever been surprised by "nasal daemons".

[MaxBarraclough]

> All this buzz about UB is a bit much.

No, the problem of undefined behaviour isn't overstated. It's the reason C and C++ have such a poor security track-record.

> I'm quite confident that I don't have much UB in my code

Plenty of C and C++ programmers are confident they don't have UB in their code, and yet we see a constant stream of security issues arising from UB in codebases developed and maintained by the smartest and most motivated C/C++ programmers, such as kernel code and the Chromium codebase.

From the Chromium project: [0]

> Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs.

These bugs are, of course, undefined behaviour. These are serious bugs that presumably made it through their code-review and code-analysis processes.

(Chromium is written in C++ rather than C, but the point stands.)

> running sanitizers from time to time confirms

It doesn't. Modern static analysis tools are pretty smart, but they're a long way from being able to detect every instance of possible UB, with no false positives. If they were, we'd be in a very different place.

With the current state-of-the-art, the only way we have of developing C/C++ codebases that are free of UB, is to use formal methods (e.g. SeL4). This approach is very rarely taken, on account of the impact on development speed, and the skill needed.

[0] https://www.chromium.org/Home/chromium-security/memory-safet...