Reducing undefined behavior in the C language

"Some Honeywell machines, for example, had nine-bit bytes."OS 2200 has 36-bit words. It is still a supported platform.https://en.wikipedia.org/wiki/UNIVAC_1100/2200_seriesThis platform was the first SMP UNIX implementation:"Any configuration supplied by Sperry, including multiprocessor ones, can run the UNIX system."https://www.nokia.com/bell-labs/about/dennis-m-ritchie/other... reply: > OS 2200 has 36-bit words. It is still a supported platform.Yes, but that's perhaps an argument for 'implementation defined behaviour', not in favour of 'undefined behaviour'.

1790620504 | Reducing undefined behavior in the C language | https://lwn.net/SubscriberLink/1095811/b9325731ea9b61e0/ | https://news.ycombinator.com/item?id=49882419 | 15 comments1790673092 | Reducing undefined behavior in the C language | https://lwn.net/SubscriberLink/1095811/efcdbcf080cfa4c6/ | https://news.ycombinator.com/item?id=49890290 | 0 comments

i've seen static analyzers catch many ub patterns, but guaranteeing zero ub needs whole‑program analysis that blows up compile time and still produces false positives that drown developers reply: Yes, it's pretty much impossible to prove anything about arbitrary programs.However if you are willing to restrict what programs you allow, you can make guarantees possible.Silly example: if you compile valid (safe) Rust programs to C, you know that the resulting code will not invalidate Rust's borrowing rules by construction; and in principle you could try to establish this guarantee just from the C code alone, never having seen the Rust original.However, you still wouldn't be able to have an algorithm that tells you for any arbitrary C code whether it has these problems or not.

The concept of undefined behaviour specific to C/C++ has always seemed batshit insane to me, and I'm yet to read anything about it that has made it seem any less so. reply: It doesn't make sense to define what happens when you e.g. read from NULL because it's hardware specific - if you have virtual memory of some sort, you'd probably get a page mapping error. If you don't (embedded, WASM), you'd read back whatever value is at that address.Does Rust define what I get when I dereference NULL in unsafe code? I doubt it, since it would require a NULL check before every pointer dereference.The only insane thing about UB is that compiler writers took what everyone understand meant "the compiler emits what it emits and you get what you get" and turned it into "since it's undefined it means it can never happen so we can delete your null check".

Make signed overflow defined please. reply: I disagree, though I wouldn't mind adding a mechanism to say that you want signed overflow to be well defined.C23 already requires 2's-complement representation for signed integer types, but signed overflow still has undefined behavior. I think that mandating 2's-complement wraparound would be a mistake.Some instances of undefined behavior can be detected at compile time. For example, if I write int too_big = INT_MAX + 1; a reasonably clever compiler can warn about it (and in fact both gcc and clang do so). If the result of INT_MAX + 1 were defined by the language to be INT_MIN, there would be no basis for such a warning.If you evaluate n + 1 and it's possible for n to be equal to INT_MAX before the addition what do you want the result to be? Would quietly yielding INT_MIN really be useful?Ideally, if I (accidentally) evaluate INT_MAX + 1, I'd like to be told that I've made a mistake. C doesn't have a good mechanism for doing so.gcc has a non-standard option "-fsanitize=signed-integer-overflow" that can be used to catch signed overflow at runtime. If signed overflow yielded a well defined result, that option would be non-conforming.