Hacker News Reader

Comment by torstenvl | Hacker News Reader

There are almost no circumstances where a crash in production code is preferable.

Can you imagine working on a complicated Excel document when you run into a 2038 bug and you lose all your work instead of just having one of your future dates calculated as being in the 1970s?

Or flying a plane and the system has to reboot midair instead of saying you're at -32768 feet of altitude?

Or there are now 2.15 billion virus definitions, so your entire security suite just stops running?

Or your Tesla stops keeping you in your lane without warning because your odometer turned over?

Most things are not Therac-25. Much more software is protecting us and our data than is exposing us to danger. Loss of data, loss of navigation, loss of safety systems or life support... simply unacceptable. Turn on -ftrapv when testing and especially when fuzzing, sure, but production code should almost always be built with -fwrapv.

View on HN

Excel maintains a recovery file of your open document. If it crashes, you can reopen Excel and will likely recover most if not all of your data. You are far more likely to corrupt data by keeping the files (primary and recovery) open in a program that is in a known-bad state.

If software crashes, it can simply be rebooted. I can't get the actual requirements for airplane control softward without paying hundreds of dollars. However, I would imagine that a reboot finish quicker than a pilot could open the manual to the "negative altitude indication" section.

> Or flying a plane and the system has to reboot midair instead of saying you're at -32768 feet of altitude?

This is exactly how Airbus's computer control philosophy works: Bail out in case of inconsistencies/unexpected errors. In the best case, this means falling back to the other (one or two) still operational redundant instances of the same component. The remediation is to literally reboot the errored-out component manually, mid-flight, with absolutely no adverse consequences. For all you know, this has already happened on a flight you've been on!

In the worst case (which can happen if it's an internally-consistent error condition, e.g. something like a conceptually unforeseen condition that none of the equivalent system instances can handle), the entire system declares failure and bails out to a lower-level system, if needed all the way down to mechanic/hydraulic connections to the most critical control surfaces in case of e.g. the A320. This can mean that e.g. the pilots need to start flying the plane manually.

Flying manually is preferred over e.g. one of two systems thinking that the plane is upside down, with a compromise action of rotating 90 degrees along some axis.

> Can you imagine working on a complicated Excel document when you run into a 2038 bug and you lose all your work instead of just having one of your future dates calculated as being in the 1970s?

if your program loses data on a crash it is not worth using. What is this, 1970?

> Or flying a plane and the system has to reboot midair instead of saying you're at -32768 feet of altitude?

I'm pretty sure that's exactly what happens in fact: a quick reboot temporarily handling control to lower level or redundant controls is better than feeding wrong information to a sophisticated flight control system. I think this is generally true for all high reliability control systems.

Crash-only software works for Erlang, and I think people expect telephony switches to be reliable. (Swift also crashes on overflows and runs your phone.)

Most of your examples would be just as bad if they started having unbounded incorrect behavior, and an overflow you didn't know about could lead to that. So don't get the math wrong!

> (Swift also crashes on overflows and runs your phone.)

AFAIK, over half of the mobile phones in the world, and probably nearly all of the fixed phones, do not run Swift, but instead some older language which does not have this "crash on overflow" behavior.

Many landline and mobile phone switches do run on Erlang. Not getting a connection in case of e.g. an integer overflow for "pick the next available trunk line" is preferable to kicking out an existing connection on line 0.

Note that an exception doesn't need to literally mean "the entire system comes to a screeching halt": You'd usually limit exception handling to the current operation.

Nobody is talking about exceptions. We're talking about intentionally invoking undefined behavior.

You don't use trap representations to handle potential overflows. You check for possible overflow prior to the operation, and then handle appropriately.

The plane example. Better to have software fault, stop and let redundant system take over. Which might be the pilot looks at another gauge. Pilot logs problem and gets looked at.

I totally disagree. Overflow almost certainly represents a bug and the violation of various invariants. Your code is doing something, even if it isn't giving radiation doses. Computing the wrong data and storing it can cause problems for customers, modify data you didn't plan on touching, or render data entirely inaccessible if various encryption operations are performed incorrectly.

Just like most things are not the Therac-25, most things are also not safety critical when they crash. Some web service that crashes just means that it returns 500 and you see it on whatever stability dashboard.

Web services are a great example. Explain to me why it's preferable to give a constant 500 and lock me out of my account, rather than having a fucked up background image scaling or whatever else your web service would be doing with arithmetic.

This is exactly right.

Reply on news.ycombinator.com