> 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<<32`, or `(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)
> 1. write your own compiler that does it right (ETOOHARD now that clang didn't)
The problem here is that "right" is not quite that black-and-white. To a lot of users, "right" is "my code appears to work," optionally with "at a given performance level." A new compiler that's slower, or changes semantics compared to some baseline, won't necessarily be seen as "better" unless there's some clear benefit, and "doesn't perform optimizations that may result in security holes" wasn't necessarily a clear benefit at the time clang was trying to gain traction. "Better error messages" and "faster compiles", on the other hand, were, and those were some of the reasons Clang gained adoption despite (sometimes?) producing slower programs.
It's somewhat analogous to Microsoft's dedication to backwards compatibility. If a program did something technically illegal and a later version of Windows broke the program, users tend to blame Microsoft and/or Windows, not the program. Same thing here - if Clang didn't perform such aggressive optimization and was slower than GCC because of it, users will tend to think "Clang is slow", not "GCC is making nonsensical optimizations" or "My program invokes UB".
This is only a matter of opinion because this mistake was made at all in the spec. If it hadn't been you'd not be saying any of the above. Most UB in C has reasonable implementation. E.g., `sizeof(enum_type)` should be 4 if its value range permits it, else 8. E.g., 1-bit int bitfields should behave like 1-bit unsigned int bitfields. I already covered bit shifting, signed integer overflows, and NULL dereferences, which covers... most things. OK, there's aliasing, but that was a terrible mistake. Really, it's not that hard.
"Clang is slow" would not be a result. "Clang produces slow code" might be due to it not deleting "unpossible" code, but screw that, you can always go delete it yourself if it was dead. The compiler deleting such code is a terrible trap.
> If it hadn't been you'd not be saying any of the above.
Well, yes, that's kind of the point. If GCC adopts that interpretation and gets a speed boost out of it, then there's pressure on Clang to do the same, unless they can convince developers that not making such aggressive optimizations is worth it. "Your code may be slower so this (arguably) edge case behaves better, but you get better error messages/compile times" is not going to be as easy to sell as "Your code will behave the same and perform as well as when compiled with GCC, and you get better error messages/compile times to boot".
> "Clang produces slow code" might be due to it not deleting "unpossible" code, but screw that, you can always go delete it yourself if it was dead.
The entire point of the dead code elimination pass is to do that for you. If anything, that's why the optimizer exists; so you don't have to perform optimizations manually.
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<<32`, or `(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:
Unsurprisingly we've ended up with (2).