GMP and assert()

Posted Mar 1, 2019 2:59 UTC (Fri) by pizza (subscriber, #46)
In reply to: GMP and assert() by mgb
Parent article: GMP and assert()

> What if the application prefers to finish landing the plane before figuring out how the library managed to violate its own invariant?

If application in question is flight-critical avionics, then every line of source code (including all libraries and compile-time settings) will have been fully audited a-priori, rendering your question moot.

That isn't to say that unanticipated issues can't happen.. indeed, safety-critical systems are typically designed under the assumption that unexpected issues _will_ occur. Consequently there are requirements that the overall system must be able to fail (and recover) gracefully.

GMP and assert()

Posted Mar 1, 2019 7:23 UTC (Fri) by mgb (guest, #3226) [Link] (4 responses)

> If application in question is flight-critical avionics, then every line of source code (including all libraries and compile-time settings) will have been fully audited a-priori, rendering your question moot.

Unmanned space missions have been lost due to typos. A navy cruiser (Yorktown) lost its computer network and propulsion because of an unexpected zero. And at least one F-22 crashed due to a software error.

GMP and assert()

Posted Mar 1, 2019 14:27 UTC (Fri) by pizza (subscriber, #46) [Link] (3 responses)

The Yorktown was being used as a testbed for a brand-new "smart ship" system architecture and its highly publicized propulsion failure was ultimately due to unsanitized user input. Meanwhile, the Mars Lander was lost was due to metric/imperial unit confusion -- essentially a failure of specification. And the only F-22 cash due to an outright software error was on an early flight test of the second prototype -- and even that was a failure to compensate for pilot-induced oscillation.

So if your point is auditing doesn't catch everything (especially in light of incomplete or incorrect specifications) then sure, we're in complete agreement.

If it's not, then I have no idea what point you are trying to make.

GMP and assert()

Posted Mar 1, 2019 16:01 UTC (Fri) by mgb (guest, #3226) [Link] (2 responses)

> So if your point is auditing doesn't catch everything (especially in light of incomplete or incorrect specifications) then sure, we're in complete agreement.

Good. Then let's allow the application do it's best to finish landing the plane before we stop to figure out how the library managed to violate its own invariant.

GMP and assert()

Posted Mar 1, 2019 18:56 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

> Then let's allow the application do it's best to finish landing the plane before we stop to figure out how the library managed to violate its own invariant.

Do I have to point out that when it comes to avionics, there is no distinction made between "the library" and "the application"?

Meanwhile, there have been quite a few situations where "the application tried to finish landing the plane" straight into the ground.

GMP and assert()

Posted Mar 2, 2019 10:02 UTC (Sat) by devkev (subscriber, #74096) [Link]

> Do I have to point out that when it comes to avionics, there is no distinction made between "the library" and "the application"?

No. It wasn't meant literally. It was meant to illustrate the idea that the application might have things that it would prefer to do on error conditions, and those things can't be done if the library's narrow view causes the whole application to be killed.

> Meanwhile, there have been quite a few situations where "the application tried to finish landing the plane" straight into the ground.

And innumerable more where the remaining systems - affected by the problem as well as unaffected - were able to be used to land the plane safely. A faulty altimeter doesn't shut down the entire plane, because the rest of the plane is _probably_ fine. But in this analogy, that is exactly what happens when a library calls abort/assert.