3 ms·

C = Control I think in the world of C, the compiler assumes the author knows what they're doing, and historically, you were probably supposed to use a separate

by xjay 3y ago

C = Control I think in the world of C, the compiler assumes the author knows what they're doing, and historically, you were probably supposed to use a separate tool, a linter [1] (static analysis tool), to help catch mistakes. HN's hard disks were a recent (2022-07) victim of a firmware developer's lack of understanding of integer overflow exceptions. [2] The firmware was likely written in C, or "C++ C". A fix was released in 2020. Another reminder to update the firmware of these disks. [3] ++crash; [1] https://en.wikipedia.org/wiki/Lint_(software) https://en.wikipedia.org/wiki/Lint_(software) [2] https://en.wikipedia.org/wiki/Integer_overflow https://en.wikipedia.org/wiki/Integer_overflow [3] https://www.thestack.technology/ssd-death-bug-40000-hours-sandisk/ https://www.thestack.technology/ssd-death-bug-40000-hours-sa...

agwa 3y ago
Undefined behavior is the opposite of programmer control. As the examples in the blog post show, you can write code that explicitly deferences a NULL pointer, or enters an infinite loop, and the compiler will think surely the programmer didn't mean to do that, and literally remove code that you wrote. It's true that historically C has not done much to protect programmers from their mistakes, but historically mistakes just meant suffering the natural consequences (such as a SIGSEGV on NULL pointer dereference). But these days, when you make a mistake, C compilers will exploit your mistake to the maximum extent possible, including changing the meaning of your programs.
Rexxar 3y ago
IMHO, having an additional debug mode where all optimisations steps are performed but with asserts inserted to validate all preconditions would mitigate a lot of problems. For example adding a "assert(x < MAX_INT - 100)" in first example. Running test suites on this debug binaries would find a lot of problems.

by xjay 3y ago

agwa 3y ago

Undefined behavior is the opposite of programmer control. As the examples in the blog post show, you can write code that explicitly deferences a NULL pointer, or enters an infinite loop, and the compiler will think surely the programmer didn't mean to do that, and literally remove code that you wrote. It's true that historically C has not done much to protect programmers from their mistakes, but historically mistakes just meant suffering the natural consequences (such as a SIGSEGV on NULL pointer dereference). But these days, when you make a mistake, C compilers will exploit your mistake to the maximum extent possible, including changing the meaning of your programs.

Rexxar 3y ago

IMHO, having an additional debug mode where all optimisations steps are performed but with asserts inserted to validate all preconditions would mitigate a lot of problems. For example adding a "assert(x < MAX_INT - 100)" in first example. Running test suites on this debug binaries would find a lot of problems.