> ignoring the situation completely with unpredictable results
That needn't mean "delete the code".
TFA is certainly right that this situation is killing C. But then, so is C's old type model. Rust is clearly better, so it's just as well.
That said, I think the C99 UB stance is a disaster for any language that might adopt it.
Perhaps the standard should not define `1(char )0`, or signed integer overflow. But it's easy enough for a compiler to implement shift overflow as 0 (or maybe -1 if the shifted number is signed and negative), it's easy enough to perform signed arithmetic and let the emitted instructions do what they will, and it's easy enough to allow NULL dereferences (maybe the app mapped a page at address 0 for some reason, or maybe you want to catch a segfault).
> But his argument against it mixes "it would be better if it worked differently" with "A specific pedantic reading of the standard says they are wrong".
I mean, if it works to shame compiler teams into serving their communities better, I'm all for it.
> The second kind of argument seems to undercut his wider point.
No, it's a plausible argument. It's like arguing about what the Founding Fathers meant by some specific clause in the Constitution.
> pointing to a possible miss-reading of a comma is not going to do much
That happens all the time in statutory and constitutional interpretation by courts. It's the same here. We're arguing the spec.
> Convincing compilers to be more reasonable is probably going to require a very different tone.
No, it's just not possible at all, tone or no tone. The right answers were always:
1. write your own compiler that does it right
(ETOOHARD now that clang didn't)
2. start over with a new language
(Hello Rust)
Unsurprisingly we've ended up with (2).