Re: Mars lander crash

Message-ID	<kgishd-74f.ln1@wilbur.25thandClement.com> (permalink)
From	<william@wilbur.25thandClement.com>
Subject	Re: Mars lander crash
Newsgroups	comp.lang.c
References	(3 earlier) <o2eel2$614$1@dont-email.me> <o2eg20$b90$1@dont-email.me> <o2emds$5ek$1@dont-email.me> <o2epuf$juu$1@dont-email.me> <o2es0l$sea$1@dont-email.me>
Date	2016-12-09 22:04 -0800

Show all headers | View raw

jacobnavia <jacob@jacob.remcomp.fr> wrote:
> Le 09/12/2016 à 18:35, David Brown a écrit :
>> The length of the code coverage tests goe up to
>> the point that the code can no longer be tested through all paths.
> 
> This is not true. Suppose we have a setup within the language like this:
> 
> Any overflow, division by zero, or other mishaps generate a signal. Most 
> CPUs can generate this signal automatically. An interrupt is generated 
> and the code is rerouted to the current handler.
> 
> Other CPUs have an overflow flag that must be tested, but that is simply 
> a technical detail that can be ignored. It introduces an extra 
> instruction, and a small delay since testing a CPU flag is very fast: no 
> I/O is involved and no memory access is done.
> 
> Any signal can be ignored by the software, or handled, according to the 
> settings of the signal mechanism. The handler should receive information 
> about the fault, making it possible to log something.
> 
> A handler can either exit the program, jump to a restart point, or 
> return a maximum value according to the type of the expected result.
> 
> This adds a common path to ALL calculations, of course. But it can be 
> tested, by supplying specially crafted data to the inputs of the program 
> under test.

It adds a common path, but because that path is taken at different places in
the code, the execution state of the program is different at each point. As
Mr. Brown explained, it explodes the cyclomatic complexity of the program,
prohibiting comprehensive code testing without manually inspecting each jump
and excluding those jumps that cannot happen. In that way you've returned to
square 0, with the automatic exception generation having only compounded
your problems.

IMO, normally the best way to handle overflow-inducing and other garbage
inputs is to make algorithms resilient to bad input. Wrap-around behavior,
saturation, etc are basic examples. The output may be semantically garbage,
but if most of your application is written that way than reasoning about and
testing garbage input is made much easier. For example, a function that
validates a cryptographic signature doesn't break (or shouldn't break) if
it's fed garabage input. Rather, the universe of all possible inputs, valid
or invalid, should be constrained to and converge to a binary output:
verified or not verified.

Things like automatic overflow checks really only make sense if it will
simply abort the task. That doesn't prohibit recovery, but it's usually best
that you unwind to a process boundary or similar boundary with minimally
shared state. In the context of C, creating those boundaries in a
fine-grained matter is difficult. And in any event those boundaries are
typically functional, not boundaries peculiar to the implementation logic;
not unlike the cryptographic function example.

For example, to be resilient to out-of-memory conditions, in my C code I
rigorously only use data structures like queues and red-black trees that are
allocation free (nodes are embedded in object structures). That minimizes
the number of places where allocation can fail, and makes it much easier to
reach a stable program state that can be reliably and properly unwound when
memory becomes scarce.

For example, if a new network connection arrives, after allocating the
connection object I can insert the connection state into various data
structures without worrying that each operation might fail. The only points
of failure are the few allocations to create the connection object, not
every line of code that modifies a list or tree. (This is not unlike the
discipline behind RAII, which is not coincidentally integral to making C++
code exception safe.)

Similarly, I try to avoid explicit overflow checking whenever practical.
Rather, I focus on ensuring that most code is intrinsically resilient to
overflow, and that the consequences of overflow converge to a smaller number
of points in the program where explicit error handling can be more safely
and more easily added.

> My objective in this discussion is to present the viewpoint that C could 
> have a standard method of making it easy to cover overflows and buffer 
> overruns. The same arguments that are marshalled against array bounds 
> checking can be mershalled against overflow testing but in both cases 
> the naysayers are wrong.
> 
> What is important here is to make it easy to avoid this kind of bugs.

Automatic exception generation doesn't avoid bugs. Avoiding bugs requires
ensuring that garbage input doesn't result in a violation of expeted state
invariants. A jump to an exception handler can have the same disastrous
effect as anything else. And signals are an especially poor way to handle
this, especially in the absense of closures and other niceties that can
isolate recovery logic like we strive to do for functional logic.

If you want to avoid a particular consequence, like arithmetic overflow
resulting in buffer overflow, that should be addressed directly by compilers
inserting instrumention to track and check object boundaries. Nothing in the
C language prohibits that.

> Note that this doesn't make any addition to the language itself. It is 
> just a standardization of the signal mechanism for covering errors.
> 
> A lot of input laundering can be avoided if you just assume that all 
> data is ok and setup a recovery schema for the errors you expect.

That's a false dichotomy. I agree that input laundering is a bad idea. But
the only alternative isn't to trap overflow in every arithmetic expression.
The trick is to design algorithms to be resilient to garbage input, and to
put error detection on the output path, preferably in as few places as is
practicable. (The need to maintain context when reporting or recovering from
an error is often in tension with keeping as few error paths as possible.)

FWIW, it's also consonant with Postel's Law: be conservative in what you do,
be liberal in what you accept. To Jon Postel that's what robustness looks
like in practice. And to my mind it's a principle that scales down to the
level of functions and even code blocks.

> Some people here say that when the overflow has happened it is "too 
> late". This is ridiculous. Error handling must be done, there is no way 
> out of it. Errors will occur and they must be simply accounted for and 
> the software designed in such a way that it responds with logic to bad 
> inputs or electrical failures.

Right, but it's _how_ you account for them that matters most.

Thread

Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-09 13:26 +0100
  Re: Mars lander crash Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 12:44 +0000
    Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 14:53 +0100
      Re: Mars lander crash already5chosen@yahoo.com - 2016-12-09 05:58 -0800
        Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 15:11 +0100
        Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-09 16:56 +0100
          Re: Mars lander crash supercat@casperkitty.com - 2016-12-09 08:51 -0800
          Re: Mars lander crash already5chosen@yahoo.com - 2016-12-11 02:23 -0800
            Re: Mars lander crash Gareth Owen <gwowen@gmail.com> - 2016-12-11 10:57 +0000
          Re: Mars lander crash "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-11 12:34 -0500
            Re: Mars lander crash Robert Wessel <robertwessel2@yahoo.com> - 2016-12-11 23:33 -0600
      Re: Mars lander crash Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 14:22 +0000
        Re: Mars lander crash asetofsymbols@gmail.com - 2016-12-09 06:30 -0800
          Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 15:48 +0100
        Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 15:46 +0100
          Re: Mars lander crash Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 14:55 +0000
            Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 16:08 +0100
              Re: Mars lander crash Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 15:52 +0000
          Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-09 17:35 +0100
            Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 18:35 +0100
              Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-09 19:10 +0100
                Re: Mars lander crash "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-09 19:18 -0500
                Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-09 16:49 -0800
                Re: Mars lander crash "J. Clarke" <j.clarke.873638@gmail.com> - 2016-12-20 20:03 -0500
                Re: Mars lander crash <william@wilbur.25thandClement.com> - 2016-12-09 22:04 -0800
                Re: Mars lander crash supercat@casperkitty.com - 2016-12-10 10:59 -0800
                Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-11 13:22 +0100
                Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 14:18 +0100
                Re: Mars lander crash already5chosen@yahoo.com - 2016-12-11 06:03 -0800
                Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 15:08 +0100
                Re: Mars lander crash already5chosen@yahoo.com - 2016-12-11 06:20 -0800
                Re: Mars lander crash luser droog <luser.droog@gmail.com> - 2016-12-11 07:08 -0800
                Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-11 11:56 -0800
                Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 21:05 +0100
                Re: Mars lander crash jameskuyper@verizon.net - 2016-12-11 12:57 -0800
                Re: Mars lander crash Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 21:26 +0000
                Re: Mars lander crash supercat@casperkitty.com - 2016-12-11 09:23 -0800
                Re: Mars lander crash Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 14:01 +0000
                Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 15:11 +0100
                Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-11 18:57 +0100
                Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 19:23 +0100
                Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-11 19:55 +0100
                Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 20:52 +0100
                Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-11 23:37 +0100
                Re: Mars lander crash supercat@casperkitty.com - 2016-12-11 16:10 -0800
                Re: Mars lander crash BartC <bc@freeuk.com> - 2016-12-12 01:13 +0000
                Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-12 09:53 +0100
                Re: Mars lander crash supercat@casperkitty.com - 2016-12-12 08:30 -0800
                Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-12 09:25 +0100
                Re: Mars lander crash supercat@casperkitty.com - 2016-12-11 10:36 -0800
                Re: Mars lander crash Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 18:46 +0000
                Re: Mars lander crash supercat@casperkitty.com - 2016-12-11 09:12 -0800
                Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 18:53 +0100
                Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-11 12:09 -0800
                Re: Mars lander crash Jean-Marc Bourguet <jm@bourguet.org> - 2016-12-11 21:30 +0100
                Re: Mars lander crash Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-11 15:50 -0500
                Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 23:02 +0100
                Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-11 18:29 -0800
                Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-11 12:03 -0800
                Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-11 11:55 -0800
                Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-11 23:42 +0100
                Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-11 14:53 -0800
                Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-12 17:09 +1300
                Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-12 10:00 +0100
                Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-12 22:20 +1300
                Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-12 01:28 -0800
                Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-12 22:38 +1300
                Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-12 02:43 -0800
                Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-13 08:20 +1300
                Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-12 12:57 -0800
                Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-13 14:14 +1300
                Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 01:19 -0800
                Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-13 22:56 +1300
                Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 05:16 -0800
                Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-14 18:05 +1300
                Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-13 08:19 -0800
                Re: Mars lander crash Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-13 17:01 +0000
                Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 10:48 -0800
                Re: Mars lander crash Geoff <geoff@invalid.invalid> - 2016-12-13 11:56 -0800
                Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 13:37 -0800
                Re: Mars lander crash Geoff <geoff@invalid.invalid> - 2016-12-13 19:11 -0800
                Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-13 20:13 +0100
                Re: Mars lander crash supercat@casperkitty.com - 2016-12-13 11:45 -0800
                Re: Mars lander crash Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-13 23:10 +0000
                Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-14 10:18 +0100
                Re: Mars lander crash Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-14 12:37 +0000
                Re: Mars lander crash Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 21:31 -0800
                Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-15 13:26 +0100
                Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-12 22:40 +1300
                Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-12 13:22 +0100
                Re: Mars lander crash supercat@casperkitty.com - 2016-12-12 08:35 -0800
        Re: Mars lander crash supercat@casperkitty.com - 2016-12-09 08:43 -0800
      Re: Mars lander crash Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 09:47 -0500
        Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 16:11 +0100
          Re: Mars lander crash Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:49 -0500
  Re: Mars lander crash already5chosen@yahoo.com - 2016-12-09 05:53 -0800
    Re: Mars lander crash asetofsymbols@gmail.com - 2016-12-09 06:04 -0800
      Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 15:09 +0100
        Re: Mars lander crash Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:06 -0500
          Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 16:32 +0100
    Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-09 17:30 +0100
      Re: Mars lander crash BartC <bc@freeuk.com> - 2016-12-09 16:42 +0000
      Re: Mars lander crash Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-09 11:43 -0500
      Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-09 08:59 -0800
      Re: Mars lander crash "J. Clarke" <j.clarke.873638@gmail.com> - 2016-12-20 19:36 -0500
  Re: Mars lander crash "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-09 06:46 -0800
    Re: Mars lander crash Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 14:57 +0000
      Re: Mars lander crash Noob <root@127.0.0.1> - 2016-12-09 16:07 +0100
    Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 16:03 +0100
      Re: Mars lander crash "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-09 12:41 -0500
    Re: Mars lander crash Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:52 -0500
      Re: Mars lander crash jameskuyper@verizon.net - 2016-12-09 12:13 -0800
        Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-09 21:56 +0100
          Re: Mars lander crash jameskuyper@verizon.net - 2016-12-09 14:11 -0800
        Re: Mars lander crash Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 22:46 -0500
          Re: Mars lander crash <william@wilbur.25thandClement.com> - 2016-12-09 22:34 -0800
          Re: Mars lander crash James Kuyper <jameskuyper@verizon.net> - 2016-12-10 18:38 -0500
      Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-11 06:06 -0800
  Re: Mars lander crash "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-12-10 01:17 +0800
  Re: Mars lander crash Ken Brody <kenbrody@spamcop.net> - 2016-12-13 14:28 -0500
  Re: Mars lander crash Ken Brody <kenbrody@spamcop.net> - 2016-12-13 14:30 -0500

csiph-web