Yeah, you "only" need to avoid undefined behavior. What do we need ASAN/UBSAN for then?

https://github.com/google/sanitizers/

Sure, Google is primarily a C++ shop, you could say that C++ is to blame and it has nothing to do with C.

But why the need for KASAN then? Which has a big track record at this point, by the way.

There are developers at google (most likely in increasing numbers) that would look like a deer caught in the headlights when asked to work on a C++ part of the code base (anecdotally according to a guy working at Google)

It is something experts must fail to do. Documented extensions fall under "undefined behavior", and a lot of real-world coding requires them. Oh, and use of header files and functions not in ISO C is undefined behavior. On a POSIX system #include <fcntl.h> provides definitions of things like F_DUPFD. But there is no reason why on some non-POSIX system, #include <fcntl.h> might not cause the rest of the translation unit to be compiled as Fortran 77. The include mechanism per se has the well-defined behavior that, if the header is found, it replaces itself by the content, which is thereby incorporated into the translation unit. But if that header isn't coming from the program, or from ISO C, then the content is not defined by ISO C.

Yeah, I have yet to meet someone who claims to write correct C code.

Mozilla decided that it was such a difficult task in C/C++ that they created their own language.

Twenty years ago I wrote C++ code that was easily verifiable to be memory safe and free of leaks, just by using a handful of smart classes and sticking to them.

"Using a handful of smart classes and sticking to them" by no means guarantees memory safety, unless you also rule out references and a bunch of other normal C++ features.

I made use of const references in the code to avoid some unnecessary refcount bumping.

I hadn't ruled out calling outside platform API functions, which were all written in C. You can't do that in any language, unless you're writing a pure text filter or calculator for the Unix command line environment (and don't count the I/O and math functions).

Twenty years ago I was also mostly a C++ dev and unless the code was 100% written by me I would never issue such statement, given the total lack of control what others in the team or binary 3rd party libraries are doing.

I still use C++ as one of my favourite hobby languages and althought it has improved a lot, using C++20 best practice across a team (lets assume it is already available), with binary dependencies, is still a challange to make it 100% memory safe.

> unless the code was 100% written by me I would never issue such statement

It was 100% written by me.

Note that the Rust devs made an entire 100% written-by-them-language to make the same claims.

It is a bit different though.

In C++ static analysis is optional, while it is part of language in Rust.

Then there is the whole language culture.

While me coming from stronger system languages, always strived for bounds checking enabled on my own C++ projects, good luck selling that to most C++ teams, even though in 99% of the use cases its impact is negligible.

Finally going all the way back to NEWP, system languages that require explicit unsafe blocks are much easier to do code review, than those where every line of code can possibly trigger unsafe behaviour, and C++ inherited lot of such cases from C.

But did you verify it never overflows? I think it is much harder to get that right without language (or compiler) support. Keep it mind that overflow is as severe as memory bug in C/C++ due to the unforgiving nature of UBs in those languages.

Had integers wrapped in a class, yes.

> that overflow is as severe as memory bug in C/C++

In practice, it isn't. In many traditional compilers it has predictable behavior (two's complement wrapping), if we're not talking about floating-point overflow.

Some programs explicitly rely on it. Compiler support can be provided for those programs.

It's simply not in the same category as memory corruption bugs.

Of course, ISO C and C++ have just one category for undefined! However, note that "undefined behavior" is a formal term which extends over beneficial areas such as documented extensions and the use of third-party libraries and headers.

> Had integers wrapped in a class, yes.

Okay, you were serious about safety. Congratulations, you are the first one I have ever come across.

I have never seen anyone else wrap integers in a class in order to use them with stable semantics.

That was practically a poster example to sell C++. Look, you can overload operators and get arrays with bounds checking, integers that trap overflows and so on.

Twenty years ago, C++ was still hot and there was a lot of interest in all sorts of techniques. Books, seminars, papers, blogs, you name it.

There is a way to use C++ template partial specialization to mimic the built-in conversion rules, like "int op long" promoting the left operan to "int". You can mirror the language in itself and bend the rules.

Is undefined behavior really that bad when it's not causing problems?

"Undefined behavior" is a broad area which covers everything from defects in a program that make it crash, to documented language and library extensions (which real-world programs can hardly avoid using).

The problem is that, just because it's not causing problems now, doesn't mean it can suddenly start causing incredibly hard to track down problems years later after an innocuous compiler upgrade...

Well I'm glad that other languages prevent experts from writing wrong code.