Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Mars lander crash |
| Date | 2016-12-11 23:37 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <o2kkd5$clp$1@dont-email.me> (permalink) |
| References | (9 earlier) <87d1gyzhsd.fsf@bsb.me.uk> <o2k3vc$ahp$1@dont-email.me> <o2k5gi$ofr$1@dont-email.me> <o2k7c2$crl$1@dont-email.me> <o2kame$cvb$1@dont-email.me> |
On 11/12/16 20:52, jacobnavia wrote:
> Le 11/12/2016 à 19:55, David Brown a écrit :
>
>> The signal mechanism is okay for a "integer overflow causes crash"
>> mechanism during testing.
>
> OK. But you go on...
>
>> But it is no use for a "overflow causes
>> saturation",
>
> No, since you can act on the info and return a result if you wish.
> The compiler can generate tables of associations between operations and
> program counter values, so, the handler can just unwind the interrupt
> call and go on with a result in the right register if the compiler
> generates those tables and the runtime knows about it.
>
> You can return a default result for the operation.
Fair enough - I can accept this would be possible. It would take a
great deal of effort, or severely restrict the compiler's code
generator. You'd need tables to keep track of which register the
results were in, and how they should be modified by the signal handler,
and how the handler should return to the main code. It strikes me as an
extraordinary effort for something that I can't see being useful in
practice, but I do accept that it is possible.
>
> or "overflow causes predictable wraparound",
>
> I do not have any idea what a predictable wraparound could be.
I was thinking of simple two's complement wraparound. It is what you
typically get with signed integer overflow on most machines, except that
now the compiler /knows/ you might get this and takes that into account
in optimising. With standard C, overflow is undefined behaviour, and
therefore unpredictable, even though for simple cases you usually have
two's complement wrapping.
>
>> or "overflow
>> detectable by the programmer at runtime",
>
> A signal always should generate an action, but some people here insist
> that this is too much for them since they are using old machines. They
> think that it would be impossible to tell the compiler that in this
> function you want overflow check or not, and they bring all kinds of
> contrieved examples to prove that this is not good for the general case.
>
>
>> or "overflow checked in
>> advance" solution.
>
> This doesn't look like a good idea for me, after the crash of that lander.
The lander crash was not caused by an overflow (or a saturation), but by
a mistake in the algorithm.
By "overflow checked in advance", I mean:
if (will_overflow_add(x, y)) {
z = maxValue; // or defaultValue, or whatever
} else {
z = x + y;
}
rather than:
z = x + y;
if (did_overflow()) {
z = maxValue; // or defaultValue, or whatever
}
>
> Maybe it wasn't overflow, but a saturation (whatever that means besides
> overflow) of the system with the noisy input data from sensors means
> that data was not laundered properly somehow isn't it?
Saturation means that when the results of an operation are too big for
the return value, you return the maximum valid value. So with 8-bit
signed integers (to keep the numbers easy), 100 + 100 returns 127 with
saturation.
Saturation is commonly used in DSP algorithms, amongst other things, and
some processors (such as many ARM devices) have dedicated saturated
arithmetic instructions.
>
> How comes that the system thought that it was underground with a
> negative height that has been mentioned in several reports? We will know
> for sure when ESA reports exactly what happened but it looks like an
> overflow, a negative height.
It could be any one of a great number of things. Signed integer
overflow sounds very unlikely - if they were using Kalman filters, then
it is quite likely that they used floating point. Failing that, they
probably used scaled integer libraries with saturation.
As Bart said previously, you can get a negative value without overflow,
such as 3 - 5. All you need is incorrect data and/or an incorrect
algorithm and/or an incorrect implementation of the algorithm.
>
> In general, an overflow is an interesting condition where it should not
> happen. It means wrong input. Reacting to wrong inputs depends on the
> application, and surely some stuff is more sensitive than others...
>
> What is interesting is the total absence of interest for treating the
> typical case, and that spotlight focus in old machines and obsolete
> stuff when we speak about C, even if machines have evolved immensely
> since only 10 years.
I am happy with the idea of trying to think of common causes of
problems, and finding ways to help programmers deal with them.
But personally, I just do not believe that signed integer overflow /is/
a "typical case". I don't see it as a big problem. And I certainly
don't see it as a likely problem in a situation like this one. Adding
to that, I don't see any kind of automatic handling of overflow (beyond
"crash to the debugger to help testing and development") as being of any
benefit if an overflow /does/ occur.
However, as I have said before, these is /my/ thoughts on the matter.
If you think differently, then that's fine. I have tried to give you
the best advice and ideas I can. You can use them or ignore them.
>
> You have a sentimental link with that old MIPS processor? OK. Do not use
> this in that processor. But why all the other people that use better
> machines than that one should be put on hold?
>
>> And for processors that don't have a suitable
>> trapping mechanism such as an "add and trap on overflow" instruction or
>> at least a "trap if overflow flag set" instruction, it would be
>> hopelessly inefficient.
>>
>
> Yes, poor guys. They will not be able to do any overflow processing.
>
> And so what?
>
> Implicitely is the idea that C is for old machines only, and some better
> language for new software isn't it Mr Brown?
No. The idea is that if something is to be /standard/ C, then it should
work well on a wide range of devices - from very small to very big, new
and old, simple and complex, fast and slow, weird and "normal". That is
one of the key features of C. If a new feature would not work well on
this wide range of systems - /including/ new, fast and powerful cpus -
it is not suitable for /standard/.
It might be fine as an extension for a particular implementation of C -
but that is a different matter.
(Again, I will use gcc as an example because I am familiar with it, and
you can easily check the details of what I write.)
Thus gcc has an /option/ "-ftrapv" to use trap-on-overflow on systems
that support it, though it is not recommended as it is not accurate due
to optimisations. It also has /extensions/ of builtin functions for
overflow handling. And it has a /debugging option/ for "sanitizing"
integer overflow.
Those are all fine tools (though "-ftrapv" is now considered outdated),
and I applaud any efforts you might make to put similar tools in your
own compiler. I am not convinced that it is the best use of your
development time, but you must be the judge of that, not me.
>
>> And like all overflow detection mechanisms, you either wave goodbye to
>> all sorts of optimisations based on the associativity and commutativity
>> of integer arithmetic, or your results and possible overflows are
>> totally dependent on the arrangement of code by the optimiser.
>>
>
> That is a quality of implementation issue. If your code analysis is
> unable to move several instructions as a block you should upgrade to a
> better one, what do you want me to do. I did not write you optimizer but
> shouldn't we check for overflow Mr Brown? I mean, OK, that mips machine
> and your strange optimizer can't cope. But that means that all people
> doing C in a modern environment should be hold down waiting that those
> situations improve?
>
>> So again, this is /one/ possible type of overflow detection that may be
>> of use to some people during testing and debugging. This might be
>> enough to make it worth the effort implementing it - but it is very far
>> from being a universal, useful, efficient and helpful method that could
>> sensibly be standardised in C.
>>
>
> The situation is already solved anyway. The C standard specifically
> prescribes SIGFPE for overflow. So actually it is that none of the C
> compilers implement this. I think this is totally wrong. It should be
> stressed to the main compiler people that the user has the right to
> receive SIGFPE when an overflow occurs as specified in
> 7.14 when defining the signals available:
> <quote>
> SIGFPE an erroneous arithmetic operation, such as zero divide or an
> operation resulting in overflow
> <end quote>
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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