> The easiest way to be sure a code path will run properly is to avoid writing it in the first place.
Agreed. So the app shouldn't contain anything extra not related to it's primary function.
However, handling error conditions reported by the operating trumps the extraneous code rule. But there are many ways to handle an error, including ignoring it if that's the proper thing to do.
Crashing is never the proper thing to do. If the program had simply exited at the very minimum, a restart would have taken a lot less time than a complete reboot of the machine. The software crashed that badly that it required a reboot of the machine.
> Why is nobody questioning the propriety of using an off-the-shelf Windows PC in safety-of-life applications?
They are, in the other threads. But using a better OS for the task wouldn't prevent the coding error the programmer did.
Let's say they chose Linux. A signal goes off or something else happens and their read call fails. Since they expect all their I/O to succeed they crash just like the Windows box.
If they bothered to handle the error and check for EINTR they'd know it was interrupted and not a hardware failure.
My point is, changing operating systems doesn't protect you from poorly coded applications.