Except everyone writing C is writing sloppy C. It’s like driving a car, there’s always a non-zero chance of an accident.
Even worse, in C the compiler is just waiting for you to trip up so it can do something weird. Think the risk of UB is overblown? I found this article from Raymond Chen enlightening: https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=633
I recently came across a rust book on how pointers aren’t just ints, because of UB.
fnmain() {
a = &1
b = &2
a++
if a == b {
*a = 3print(b)
}
}
This may either: not print anything, print 3 or print 2.
Depending on the compiler, since b isn’t changed at all, it might optimize the print for print(2) instead of print(b). Even though everyone can agree that it should either not print anything or 3, but never 2.
A compiler making assumptions like that about undefined behaviour sounds just like a bug. Maybe the bug is in the spec rather than the compiler, but I can’t think of any time it would be better to optimize that code out entirely because UB is detected rather than just throwing an error or warning and otherwise ignoring the edge cases where the behaviour might break. It sounds like the worst possible option exactly for the reasons listed in that blog.
If you’re writing sloppy C code your assembly code probably won’t work either
Except everyone writing C is writing sloppy C. It’s like driving a car, there’s always a non-zero chance of an accident.
Even worse, in C the compiler is just waiting for you to trip up so it can do something weird. Think the risk of UB is overblown? I found this article from Raymond Chen enlightening: https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=633
I recently came across a rust book on how pointers aren’t just ints, because of UB.
fn main() { a = &1 b = &2 a++ if a == b { *a = 3 print(b) } }This may either: not print anything, print 3 or print 2.
Depending on the compiler, since b isn’t changed at all, it might optimize the print for
print(2)instead ofprint(b). Even though everyone can agree that it should either not print anything or 3, but never 2.A compiler making assumptions like that about undefined behaviour sounds just like a bug. Maybe the bug is in the spec rather than the compiler, but I can’t think of any time it would be better to optimize that code out entirely because UB is detected rather than just throwing an error or warning and otherwise ignoring the edge cases where the behaviour might break. It sounds like the worst possible option exactly for the reasons listed in that blog.
I hope you are not argueing that using assembly is an improvement over using C in that regard…