Where he gives plenty of examples of UB resulting in the compiler optimizing away safety and introducing security vulnerabilities silently. In part 3 he discusses the efforts clang has made to improve on this.

He then went on to make Swift and says this: "Undefined behavior is the enemy of safety, and developer mistakes should be caught before software is in production."

and

"UB is an inseperable part of C programming, […] this is a depressing and faintly terrifying thing. The tooling built around the C family of languages helps make the situation less bad, but it is still pretty bad. The only solution is to move to new programming languages that dont inherit the problem of C."

[–] lysdexic -2 points 11 months ago* (last edited 11 months ago)

Where he gives plenty of examples of UB resulting in the compiler optimizing away safety and introducing security vulnerabilities silently.

That's the bit that those who parrot on abot UB get entirely wrong, and yet cling to it if it was something meaningful.

Let's make this absolutely clear: any code you write that triggers UB is a a bug you introduced. Your complains about UB boil down to blaming the language for bugs you created because you didn't knew what you were doing.

As you can configure compilers and static code analysis tools to flag UB as warnings or even errors, the discussion of using UB in your code is a discussion on incompetence. Complaining that a programming language purposely leaves out the specification of the behavior that broken code should have because you don't know what you're doing is the definition of a bad workman blaming his tools.

If you paid attention to the article you're quoting, you'd notice that even the author makes it quite clear that programs with UB only "appear to work". That boils down to the definition of UB, and the reason why every single developer in the world who had any intro to C or C++ experience knows quite well that UB means broken code. Why is it hard for you to understand this?