back
5 comments
The very first item listed jumped right out at me. "Complete catalog of all undefined behavior (UB) in C++". And further down, "Telecon line-by-line review of a proposal to systematically address all undefined behavior in C++":

> "This was, pardon my French, a “[metric] ton” of work over the course of several years. Thanks Shafik, Joshua, Timur, Jens, and everyone who helped them compile this detailed catalog so that now we can next systematically do something about these UB cases!"

I wonder if that already been done for C. Many whiners like to shout for a "safe" C or C++ dialect that's free of UB, but then deflect when asked how to specify such a thing. Listing all the ways to get UB is at least a start.

Added: a UB-elimination rampage doesn't sound like a great idea to me, after hearing many calls e.g. to remove the signed-int overflow UB by defining signed arithmetic as 2s complement. That means (in a toy example of 4-bit integers) mandating that 5+5=-6 if I have it right.

It's way preferable to do what Ada does and allow specifying the exact valid range of an integer type and mandating checked arithmetic. A compiler pragma could then allow an unsafe addition (maybe 2's complement) if you wanted to disable the check in in a hot loop or something. That's sort of what C does now, where the compiler can choose to signal an error on every occurrence of an int overflow (since it's UB, the compiler can do whatever it wants).

C has had a catalog of undefined behavior since C99, Annex J. There's sample code demonstrating all cases too.

It's worth noting (as the report itself does) that these sorts of lists can only document explicitly undefined behavior, and not the much larger universe of implicitly undefined behavior. So they're not strictly all possible UB, just the most important cases.

I believe the aim of this C++ paper is to identify all possible UB in the standard. They mention the possibility of implicit UB but take the view that if that exists, that means the standard didn't sufficiently specify what to do in situation X, i.e. it's a bug in the standard that needs a fix.
Any change in basic arithmetic should be backwards-compatible. The easiest way to eliminate UB is to define signed overflow for existing types as 2-complement. But new types with different semantics (or maybe library wrappers) can be created - with saturation, panic on overflow, or even with arithmetic operations producing extended types (like u16 + u16 = u17, u8 * u8 = u16 ).
I'm looking through the UB paper https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p31... and I haven't gotten to the good parts yet (how to handle the UB) but it looks like they're taking what I'd call a better approach. Runtime UB results from violation of an implicit contract (e.g. int arithmetic has an implicit contract that the result should not overflow), so they want to let you specify what should happen in those situations (panic, give some wrong result and keep going, call some kind of exception handler, etc.)

Defining int arithmetic as 2's complement would be a big mistake imho. It's fine if there's additional types for 2's complement, saturation, etc. But the only sane well-defined behaviour for int overflow is trap or panic (like in Ada), so in principle there should always be runtime checks. Otherwise you lose obvious invariants like n+1>n for all integers n. It's unfortunate that today's hardware makes runtime checks a big pain for integers even though it's done with no discernible overhead by the floating point hardware (IEEE-754 overflow trap etc). Oh well.