Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #98489 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2016-12-09 13:26 +0100 |
| Last post | 2016-12-13 14:30 -0500 |
| Articles | 20 on this page of 121 — 28 participants |
Back to article view | Back to comp.lang.c
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
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-09 13:26 +0100 |
| Subject | Mars lander crash |
| Message-ID | <o2e7s1$ea6$1@dont-email.me> |
The european mars lander hitted the mars surface at 300Km/hr What happened? The altimeter when started working (after the heath shield separation) gave wrong data during one second. The software wasn't prepared for an overflow, and took that wrong data at face value, what produced a NEGATIVE altitude. The lander then, thinking it had already landed, stopped the rocket motors and started the sequence for after the landing, hitting the ground at more than 200 Km per hour. Overflows are dangerous stuff. But not everything went bad. The altitude was calculated much faster than what it would, if they would have tested for overflow at each operation. Speed is important for software. Not the results.
[toc] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-09 12:44 +0000 |
| Message-ID | <o2e8sg$hp7$1@dont-email.me> |
| In reply to | #98489 |
On 09/12/16 12:26, jacobnavia wrote: > The european mars lander hitted the mars surface at 300Km/hr > > What happened? > > The altimeter when started working (after the heath shield separation) > gave wrong data during one second. > > The software wasn't prepared for an overflow, Well, it should have been. The programmer should have predicted that overflow could happen, and chosen data types that made this impossible for the (highly predictable) numbers involved. If no native data types would do, a suitable data structure should have been devised. It's not difficult. > and took that wrong data > at face value, what produced a NEGATIVE altitude. If that's what went wrong (and it's not entirely clear whether an overflow was responsible, but let's assume it was), then that is clear evidence of inadequate testing of the software. In such circumstances, an implementation that tests every operation for overflow would have been an invaluable testing tool. > The lander then, thinking it had already landed, stopped the rocket > motors and started the sequence for after the landing, hitting the > ground at more than 200 Km per hour. > > Overflows are dangerous stuff. Right. Nobody is disputing that, are they? > But not everything went bad. The altitude was calculated much faster > than what it would, if they would have tested for overflow at each > operation. > > Speed is important for software. Not the results. Nobody has claimed this, apart from you. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-09 14:53 +0100 |
| Message-ID | <o2ecu8$v73$1@dont-email.me> |
| In reply to | #98492 |
On 09/12/16 13:44, Richard Heathfield wrote: > On 09/12/16 12:26, jacobnavia wrote: >> The european mars lander hitted the mars surface at 300Km/hr >> >> What happened? >> >> The altimeter when started working (after the heath shield separation) >> gave wrong data during one second. >> >> The software wasn't prepared for an overflow, > > Well, it should have been. The programmer should have predicted that > overflow could happen, and chosen data types that made this impossible > for the (highly predictable) numbers involved. If no native data types > would do, a suitable data structure should have been devised. It's not > difficult. That is not really accurate - the software should not have been prepared for an overflow. The data should have been vetted so that there was no overflow. There are three correct ways to handle this sort of situation: 1. The code that reads the altimeter should have checked the values, and made sure they were valid and in a suitable range before passing them on to the code that uses those values. It would then be impossible for that code to experience overflow. 2. The code that used the altimeter values should have checked the values it received, and either discarded them or "saturated" them to the maximum valid value. It would then be impossible for that code to experience overflow. 3. The code that used the altimeter values should have used types with sufficient range that there would be no overflow, regardless of the value it received. It would then be impossible for that code to experience overflow. Overflow checking is about figuring out what went wrong after something /has/ gone wrong. Safe coding is about making sure things don't go wrong in the first place. Now, there is nothing wrong with understanding that programmers make mistakes, and adding additional checks or limitations to limit the damage if there is a software bug - but the prime design point here is that you do not let overflow happen. > >> and took that wrong data >> at face value, what produced a NEGATIVE altitude. > > If that's what went wrong (and it's not entirely clear whether an > overflow was responsible, but let's assume it was), then that is clear > evidence of inadequate testing of the software. In such circumstances, > an implementation that tests every operation for overflow would have > been an invaluable testing tool. I agree about inadequate testing of the software. I don't agree that testing all operations for overflow is helpful. That merely introduces a vast number of code paths that cannot be taken, cannot be tested, and cannot be verified. In a system that needs to be safe and reliable, you do not put in extra code (explicitly by the programmer, or implicitly via the tools) that you cannot test and do not need. (You do put in extra checks at boundary points between modules, but you limit these and check them independently.) > >> The lander then, thinking it had already landed, stopped the rocket >> motors and started the sequence for after the landing, hitting the >> ground at more than 200 Km per hour. >> >> Overflows are dangerous stuff. > > Right. Nobody is disputing that, are they? Not that I can see. Even though I am arguing against hidden compiler-based overflow detection, except perhaps as a debugging tool during development, I agree that overflows are dangerous. That is why I say they should be avoided, not detected. > >> But not everything went bad. The altitude was calculated much faster >> than what it would, if they would have tested for overflow at each >> operation. >> >> Speed is important for software. Not the results. > > Nobody has claimed this, apart from you. >
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2016-12-09 05:58 -0800 |
| Message-ID | <91e540d9-f110-4665-912d-5200cc0bc104@googlegroups.com> |
| In reply to | #98498 |
On Friday, December 9, 2016 at 3:53:40 PM UTC+2, David Brown wrote: > On 09/12/16 13:44, Richard Heathfield wrote: > > On 09/12/16 12:26, jacobnavia wrote: > >> The european mars lander hitted the mars surface at 300Km/hr > >> > >> What happened? > >> > >> The altimeter when started working (after the heath shield separation) > >> gave wrong data during one second. > >> > >> The software wasn't prepared for an overflow, > > > > Well, it should have been. The programmer should have predicted that > > overflow could happen, and chosen data types that made this impossible > > for the (highly predictable) numbers involved. If no native data types > > would do, a suitable data structure should have been devised. It's not > > difficult. > > That is not really accurate - the software should not have been prepared > for an overflow. The data should have been vetted so that there was no > overflow. > > There are three correct ways to handle this sort of situation: > > 1. The code that reads the altimeter should have checked the values, and > made sure they were valid and in a suitable range before passing them on > to the code that uses those values. It would then be impossible for > that code to experience overflow. > > 2. The code that used the altimeter values should have checked the > values it received, and either discarded them or "saturated" them to the > maximum valid value. It would then be impossible for that code to > experience overflow. That's what it did. > > 3. The code that used the altimeter values should have used types with > sufficient range that there would be no overflow, regardless of the > value it received. It would then be impossible for that code to > experience overflow. > That's what it did. > > Overflow checking is about figuring out what went wrong after something > /has/ gone wrong. Safe coding is about making sure things don't go > wrong in the first place. > "Overflow" is invention of jacobnavia The real reason appears to be a bad algorithm. Which of course hint at much deeper level of incompetence than suggested by jacobnavia. > Now, there is nothing wrong with understanding that programmers make > mistakes, and adding additional checks or limitations to limit the > damage if there is a software bug - but the prime design point here is > that you do not let overflow happen. > > > > > >> and took that wrong data > >> at face value, what produced a NEGATIVE altitude. > > > > If that's what went wrong (and it's not entirely clear whether an > > overflow was responsible, but let's assume it was), then that is clear > > evidence of inadequate testing of the software. In such circumstances, > > an implementation that tests every operation for overflow would have > > been an invaluable testing tool. > > I agree about inadequate testing of the software. I don't agree that > testing all operations for overflow is helpful. That merely introduces > a vast number of code paths that cannot be taken, cannot be tested, and > cannot be verified. In a system that needs to be safe and reliable, you > do not put in extra code (explicitly by the programmer, or implicitly > via the tools) that you cannot test and do not need. (You do put in > extra checks at boundary points between modules, but you limit these and > check them independently.) > > > > >> The lander then, thinking it had already landed, stopped the rocket > >> motors and started the sequence for after the landing, hitting the > >> ground at more than 200 Km per hour. > >> > >> Overflows are dangerous stuff. > > > > Right. Nobody is disputing that, are they? > > Not that I can see. Even though I am arguing against hidden > compiler-based overflow detection, except perhaps as a debugging tool > during development, I agree that overflows are dangerous. That is why I > say they should be avoided, not detected. > > > > >> But not everything went bad. The altitude was calculated much faster > >> than what it would, if they would have tested for overflow at each > >> operation. > >> > >> Speed is important for software. Not the results. > > > > Nobody has claimed this, apart from you. > >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-09 15:11 +0100 |
| Message-ID | <o2ee0l$3da$2@dont-email.me> |
| In reply to | #98501 |
On 09/12/16 14:58, already5chosen@yahoo.com wrote: > > "Overflow" is invention of jacobnavia > The real reason appears to be a bad algorithm. Which of course hint at much deeper level of incompetence than suggested by jacobnavia. > I don't know the details of what went wrong - like Richard, I have simply assumed there was an overflow since Jacob brought it up as an example. I am sure you are correct that the error was algorithmic, however - it is hard to imagine that the programmers got something as basic as integer overflow wrong.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-09 16:56 +0100 |
| Message-ID | <o2ek4p$q0s$1@dont-email.me> |
| In reply to | #98501 |
Le 09/12/2016 à 14:58, already5chosen@yahoo.com a écrit : > "Overflow" is invention of jacobnavia > The real reason appears to be a bad algorithm. Which of course hint at much deeper level of incompetence than suggested by jacobnavia. Well 1) Thanks for confirming that I invented overflow. What a discovery I did! 2) How can you explain (if it wasn't an overflow) that the height changed sign?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-09 08:51 -0800 |
| Message-ID | <b55ec764-93ad-4767-8417-86b40d1c3505@googlegroups.com> |
| In reply to | #98540 |
On Friday, December 9, 2016 at 9:56:34 AM UTC-6, jacobnavia wrote: > 2) How can you explain (if it wasn't an overflow) that the height > changed sign? Hypothetical example: radar measurement device sends out pings periodically and then times how long it takes to get a response. Software knows that because of delays in the transmission and reception mechanisms even an altitude of zero would have a certain delay between enabling the transmitter and hearing the response, so it subtracts that zero-altitude time from the actual time. The interval between pings is expected to be longer than the echo time at the longest range where an echo would be detectable at all. If that assumption holds, taking the time between transmit and receive, subtracting the zero-altitude time, and multiplying by 3.0E8 m/s should yield the altitude. If, however, an echo from an earlier ping is received just after a pulse is sent, that could result in a perceived negative altitude if code doesn't do a sanity check for that condition.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2016-12-11 02:23 -0800 |
| Message-ID | <a05589b4-42a9-447e-8f8d-648a8ec88910@googlegroups.com> |
| In reply to | #98540 |
On Friday, December 9, 2016 at 5:56:34 PM UTC+2, jacobnavia wrote: > Le 09/12/2016 à 14:58, already5chosen@yahoo.com a écrit : > > "Overflow" is invention of jacobnavia > > The real reason appears to be a bad algorithm. Which of course hint at much deeper level of incompetence than suggested by jacobnavia. > > Well > > 1) Thanks for confirming that I invented overflow. What a discovery I did! > Jacob, Most of the time, you sound like intelligent person. So, please, don't pretend that you didn't understand what I meant. All available reports mention saturated reading, which pretty much assures that integer overflow didn't happen. > 2) How can you explain (if it wasn't an overflow) that the height > changed sign? Result of Kalman filter or of similar algorithm. Taken uncritically by the rest of program logic.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-12-11 10:57 +0000 |
| Message-ID | <87fulu68dr.fsf@gmail.com> |
| In reply to | #98772 |
already5chosen@yahoo.com writes: >> 2) How can you explain (if it wasn't an overflow) that the height >> changed sign? > > Result of Kalman filter or of similar algorithm. Taken uncritically by > the rest of program logic. Doesn't even have to be anything as complicated as a Kalman filter. If you say delta(estimated_height) = estimated_velocity * delta(t) then an overlarge (saturated) descent velocity reading will cause delta height to become large and negative.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-12-11 12:34 -0500 |
| Message-ID | <3632c43a-acf5-2847-e092-aaaddcaa6fe3@verizon.net> |
| In reply to | #98540 |
On Friday, December 9, 2016 at 5:56:34 PM UTC+2, jacobnavia wrote: > Le 09/12/2016 à 14:58, already5chosen@yahoo.com a écrit : > > "Overflow" is invention of jacobnavia > > The real reason appears to be a bad algorithm. Which of course hint at much deeper level of incompetence than suggested by jacobnavia. > > Well > > 1) Thanks for confirming that I invented overflow. What a discovery I did! What he apparently meant, but did not clearly say, is that you invented overflow as an explanation for the failure of the european mars lander. The most detailed explanations I've seen talk about saturation (not overflow) of a detector being handled incorrectly by the algorithm that collected the output from that detector and used it to calculate an estimated position for the spacecraft. They don't mention any overflow in the calculations themselves. > 2) How can you explain (if it wasn't an overflow) that the height > changed sign? According to <http://www.esa.int/Our_Activities/Space_Science/ExoMars/Schiaparelli_landing_investigation_makes_progress>, the unexplained saturation of the IMU lasted for no more than a second, and caused the navigation system of the satellite to believe that it was at a negative altitude, when the actual altitude was 3.7km. However, that report also indicates that "The IMU measures the rotation rates of the vehicle.". I don't do satellite navigation, but I do use satellite navigation data, and have a fairly good idea how it is calculated. An erroneous rotation rate should, in itself, only produce an error in the estimated attitude, not in the estimated altitude. Whatever the actual problem was, it must have been more indirect. I don't think we have enough information to justify assuming that overflow was involved.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-11 23:33 -0600 |
| Message-ID | <6ads4c9jvu9jkmrmdpcng02qp20rig91gu@4ax.com> |
| In reply to | #98844 |
On Sun, 11 Dec 2016 12:34:27 -0500, "James R. Kuyper" <jameskuyper@verizon.net> wrote: >On Friday, December 9, 2016 at 5:56:34 PM UTC+2, jacobnavia wrote: >> Le 09/12/2016 à 14:58, already5chosen@yahoo.com a écrit : >> > "Overflow" is invention of jacobnavia >> > The real reason appears to be a bad algorithm. Which of course hint at much deeper level of incompetence than suggested by jacobnavia. >> >> Well >> >> 1) Thanks for confirming that I invented overflow. What a discovery I did! > >What he apparently meant, but did not clearly say, is that you invented >overflow as an explanation for the failure of the european mars lander. >The most detailed explanations I've seen talk about saturation (not >overflow) of a detector being handled incorrectly by the algorithm that >collected the output from that detector and used it to calculate an >estimated position for the spacecraft. They don't mention any overflow >in the calculations themselves. > >> 2) How can you explain (if it wasn't an overflow) that the height >> changed sign? > >According to ><http://www.esa.int/Our_Activities/Space_Science/ExoMars/Schiaparelli_landing_investigation_makes_progress>, >the unexplained saturation of the IMU lasted for no more than a second, >and caused the navigation system of the satellite to believe that it was >at a negative altitude, when the actual altitude was 3.7km. However, >that report also indicates that "The IMU measures the rotation rates of >the vehicle.". I don't do satellite navigation, but I do use satellite >navigation data, and have a fairly good idea how it is calculated. An >erroneous rotation rate should, in itself, only produce an error in the >estimated attitude, not in the estimated altitude. Whatever the actual >problem was, it must have been more indirect. I don't think we have >enough information to justify assuming that overflow was involved. That may be an oversimplification somewhere too - IMUs measuring forces on six axes (three rotational, three linear), is pretty close to universal. Something measuring rotational rates only would more likely be described as some sort of attitude measuring device (say, an "artificial horizon" in an airplane). OTOH, there are definitely (older) examples, of systems called that measuring only the forces on the linear axes (although those were almost always paired with some sort of attitude-maintaining platform, so that rotations of the vehicle didn't impact the measurements).
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-09 14:22 +0000 |
| Message-ID | <o2eel2$614$1@dont-email.me> |
| In reply to | #98498 |
On 09/12/16 13:53, David Brown wrote: > On 09/12/16 13:44, Richard Heathfield wrote: >> On 09/12/16 12:26, jacobnavia wrote: >>> The european mars lander hitted the mars surface at 300Km/hr >>> >>> What happened? >>> >>> The altimeter when started working (after the heath shield separation) >>> gave wrong data during one second. >>> >>> The software wasn't prepared for an overflow, >> >> Well, it should have been. The programmer should have predicted that >> overflow could happen, and chosen data types that made this impossible >> for the (highly predictable) numbers involved. If no native data types >> would do, a suitable data structure should have been devised. It's not >> difficult. > > That is not really accurate - the software should not have been prepared > for an overflow. The data should have been vetted so that there was no > overflow. That's kind of what I was getting at when I mentioned "highly predictable" numbers, but you said it much better than I did. > There are three correct ways to handle this sort of situation: > > 1. The code that reads the altimeter should have checked the values, and > made sure they were valid and in a suitable range before passing them on > to the code that uses those values. It would then be impossible for > that code to experience overflow. > > 2. The code that used the altimeter values should have checked the > values it received, and either discarded them or "saturated" them to the > maximum valid value. It would then be impossible for that code to > experience overflow. > > 3. The code that used the altimeter values should have used types with > sufficient range that there would be no overflow, regardless of the > value it received. It would then be impossible for that code to > experience overflow. No argument with any of those. I've left them in for context. > Overflow checking is about figuring out what went wrong after something > /has/ gone wrong. Safe coding is about making sure things don't go > wrong in the first place. This is the big problem I see with Jacob's take on overflow. By the time overflow happens, it's already too late. That's why it's fine for debug mode and test mode, but you don't want to be relying on it in production. > Now, there is nothing wrong with understanding that programmers make > mistakes, and adding additional checks or limitations to limit the > damage if there is a software bug - but the prime design point here is > that you do not let overflow happen. Right. >>> and took that wrong data >>> at face value, what produced a NEGATIVE altitude. >> >> If that's what went wrong (and it's not entirely clear whether an >> overflow was responsible, but let's assume it was), then that is clear >> evidence of inadequate testing of the software. In such circumstances, >> an implementation that tests every operation for overflow would have >> been an invaluable testing tool. > > I agree about inadequate testing of the software. I don't agree that > testing all operations for overflow is helpful. That merely introduces > a vast number of code paths that cannot be taken, cannot be tested, and > cannot be verified. I don't see how you derive that conclusion from what I wrote. Let us assume that, /without/ overflow checking, we have a battery of, say, a million tests. (This is rocket science, after all. But it's just a number. Don't get hung up on it.) And these million tests can be run in, say, a week. I see no harm, and some gain, in adding overflow checking during these existing tests. Cost? Maybe it runs in 169 hours instead of 168. No big deal. Potential value in terms of discovering an otherwise hidden overflow? Possibly considerable. It's not something I would turn down unless there were a very good reason to turn it down. > In a system that needs to be safe and reliable, you > do not put in extra code (explicitly by the programmer, or implicitly > via the tools) that you cannot test and do not need. (You do put in > extra checks at boundary points between modules, but you limit these and > check them independently.) Not in the production code, no. But for testing, I would disagree. Adding extra code can pay off during the debugging and test phases. Assertions are an obvious example. >>> The lander then, thinking it had already landed, stopped the rocket >>> motors and started the sequence for after the landing, hitting the >>> ground at more than 200 Km per hour. >>> >>> Overflows are dangerous stuff. >> >> Right. Nobody is disputing that, are they? > > Not that I can see. Even though I am arguing against hidden > compiler-based overflow detection, except perhaps as a debugging tool > during development, I agree that overflows are dangerous. That is why I > say they should be avoided, not detected. Yes, but where is the harm in detecting them anyway (during testing)? If you find one, you know you didn't avoid it! And that's useful information to the developer. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2016-12-09 06:30 -0800 |
| Message-ID | <a2eacc98-f406-4351-918b-9aeee7591f33@googlegroups.com> |
| In reply to | #98505 |
I say that all can fail... Can fail the function call this function, can fail this function, can fail the function or operator call in this function (or the detector that return measure)... Trick could be what to do in case of error number 0x12345678
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-09 15:48 +0100 |
| Message-ID | <o2eg51$b90$2@dont-email.me> |
| In reply to | #98506 |
On 09/12/16 15:30, asetofsymbols@gmail.com wrote: > I say that all can fail... Can fail the function call this function, can fail this function, can fail the function or operator call in this function (or the detector that return measure)... Trick could be what to do in case of error number 0x12345678 > Can fail write a post that sense makes?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-09 15:46 +0100 |
| Message-ID | <o2eg20$b90$1@dont-email.me> |
| In reply to | #98505 |
On 09/12/16 15:22, Richard Heathfield wrote:
> On 09/12/16 13:53, David Brown wrote:
>> On 09/12/16 13:44, Richard Heathfield wrote:
<snip the bits we are clear on>
>>> If that's what went wrong (and it's not entirely clear whether an
>>> overflow was responsible, but let's assume it was), then that is clear
>>> evidence of inadequate testing of the software. In such circumstances,
>>> an implementation that tests every operation for overflow would have
>>> been an invaluable testing tool.
>>
>> I agree about inadequate testing of the software. I don't agree that
>> testing all operations for overflow is helpful. That merely introduces
>> a vast number of code paths that cannot be taken, cannot be tested, and
>> cannot be verified.
>
> I don't see how you derive that conclusion from what I wrote. Let us
> assume that, /without/ overflow checking, we have a battery of, say, a
> million tests. (This is rocket science, after all. But it's just a
> number. Don't get hung up on it.) And these million tests can be run in,
> say, a week. I see no harm, and some gain, in adding overflow checking
> during these existing tests. Cost? Maybe it runs in 169 hours instead of
> 168. No big deal. Potential value in terms of discovering an otherwise
> hidden overflow? Possibly considerable. It's not something I would turn
> down unless there were a very good reason to turn it down.
In the tests without overflow checking, you have code like this:
if (a) {
x = y + z;
}
This gives you two paths to check, one of which involves a calculation.
If you add overflow checking, you have this:
if (a) {
x = y + z;
if (overflow) {
doSomethingAboutTheOverflow();
}
}
For every calculation with overflow checking, you have added another
code path to check. If you have not gone down that path, your tests
don't have full coverage of the code you have written.
If the action on overflows is all the same - jump to safe mode, deploy
parachutes and airbags, panic, prey, say your last farewells - then it
is possible that the testing is feasible if you have some way to
artificially inject overflows in code that you know cannot possible
/have/ overflows. But if the action on overflows is a recovery, or an
exception-type mechanism, then you have hugely multiplied up the number
of possible code paths in each function. Your cyclomatic complexity
goes through the roof, and instead of /adding/ an hour to your test, you
are multiplying it by 2 to the power of the number of calculations in a
function.
>
>> In a system that needs to be safe and reliable, you
>> do not put in extra code (explicitly by the programmer, or implicitly
>> via the tools) that you cannot test and do not need. (You do put in
>> extra checks at boundary points between modules, but you limit these and
>> check them independently.)
>
> Not in the production code, no. But for testing, I would disagree.
> Adding extra code can pay off during the debugging and test phases.
> Assertions are an obvious example.
Yes, more code (such as asserts) can be useful during early testing -
the sooner you find the bugs, the better.
For your long-term testing, of course, you use the production version.
(These kinds of tests may run in parallel to some extent.)
>
>>>> The lander then, thinking it had already landed, stopped the rocket
>>>> motors and started the sequence for after the landing, hitting the
>>>> ground at more than 200 Km per hour.
>>>>
>>>> Overflows are dangerous stuff.
>>>
>>> Right. Nobody is disputing that, are they?
>>
>> Not that I can see. Even though I am arguing against hidden
>> compiler-based overflow detection, except perhaps as a debugging tool
>> during development, I agree that overflows are dangerous. That is why I
>> say they should be avoided, not detected.
>
> Yes, but where is the harm in detecting them anyway (during testing)? If
> you find one, you know you didn't avoid it! And that's useful
> information to the developer.
>
Agreed - overflow detection is a debugging tool. At the risk of causing
another explosion, tools such as gcc/clang's
"-fsanitize=signed-integer-overflow" can definitely be useful in
spotting bugs during development and testing.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-09 14:55 +0000 |
| Message-ID | <o2eghr$d3o$1@dont-email.me> |
| In reply to | #98507 |
On 09/12/16 14:46, David Brown wrote:
> On 09/12/16 15:22, Richard Heathfield wrote:
>> On 09/12/16 13:53, David Brown wrote:
>>> On 09/12/16 13:44, Richard Heathfield wrote:
>
> <snip the bits we are clear on>
>
>>>> If that's what went wrong (and it's not entirely clear whether an
>>>> overflow was responsible, but let's assume it was), then that is clear
>>>> evidence of inadequate testing of the software. In such circumstances,
>>>> an implementation that tests every operation for overflow would have
>>>> been an invaluable testing tool.
>>>
>>> I agree about inadequate testing of the software. I don't agree that
>>> testing all operations for overflow is helpful. That merely introduces
>>> a vast number of code paths that cannot be taken, cannot be tested, and
>>> cannot be verified.
>>
>> I don't see how you derive that conclusion from what I wrote. Let us
>> assume that, /without/ overflow checking, we have a battery of, say, a
>> million tests. (This is rocket science, after all. But it's just a
>> number. Don't get hung up on it.) And these million tests can be run in,
>> say, a week. I see no harm, and some gain, in adding overflow checking
>> during these existing tests. Cost? Maybe it runs in 169 hours instead of
>> 168. No big deal. Potential value in terms of discovering an otherwise
>> hidden overflow? Possibly considerable. It's not something I would turn
>> down unless there were a very good reason to turn it down.
>
> In the tests without overflow checking, you have code like this:
>
> if (a) {
> x = y + z;
> }
>
> This gives you two paths to check, one of which involves a calculation.
>
> If you add overflow checking, you have this:
>
> if (a) {
> x = y + z;
> if (overflow) {
> doSomethingAboutTheOverflow();
> }
> }
No no no no no no no!
No.
No, we're talking about the *implementation* inserting code. Your source
code does not change *at all*. And you can switch it off. If you're
concerned that the introduction of the implementation's overflow check
creates hidden code paths within the object code (and that's a perfectly
reasonable concern), then here's what you do:
1) run the tests /without/ overflow checking. 168 hours. Fine,
everything passed --- keep going as if all is well (because, as far as
you know, it is), BUT...
2) find an old computer that's propping open a door, and set it to
running the same tests, this time with overflow checking enabled. 169
hours of electricity, but it's not holding you up. In fact, it *only*
holds you up if, 169 hours later, it says "BEEP! I found an overflow!"
in which case you surely do want to know about it.
<snip> - and, in the bit I snipped, you cover some of the above, so I
think we may be in violent agreement.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-09 16:08 +0100 |
| Message-ID | <o2ehb4$g0s$1@dont-email.me> |
| In reply to | #98512 |
On 09/12/16 15:55, Richard Heathfield wrote:
> On 09/12/16 14:46, David Brown wrote:
>> On 09/12/16 15:22, Richard Heathfield wrote:
>>> On 09/12/16 13:53, David Brown wrote:
>>>> On 09/12/16 13:44, Richard Heathfield wrote:
>>
>> <snip the bits we are clear on>
>>
>>>>> If that's what went wrong (and it's not entirely clear whether an
>>>>> overflow was responsible, but let's assume it was), then that is clear
>>>>> evidence of inadequate testing of the software. In such circumstances,
>>>>> an implementation that tests every operation for overflow would have
>>>>> been an invaluable testing tool.
>>>>
>>>> I agree about inadequate testing of the software. I don't agree that
>>>> testing all operations for overflow is helpful. That merely introduces
>>>> a vast number of code paths that cannot be taken, cannot be tested, and
>>>> cannot be verified.
>>>
>>> I don't see how you derive that conclusion from what I wrote. Let us
>>> assume that, /without/ overflow checking, we have a battery of, say, a
>>> million tests. (This is rocket science, after all. But it's just a
>>> number. Don't get hung up on it.) And these million tests can be run in,
>>> say, a week. I see no harm, and some gain, in adding overflow checking
>>> during these existing tests. Cost? Maybe it runs in 169 hours instead of
>>> 168. No big deal. Potential value in terms of discovering an otherwise
>>> hidden overflow? Possibly considerable. It's not something I would turn
>>> down unless there were a very good reason to turn it down.
>>
>> In the tests without overflow checking, you have code like this:
>>
>> if (a) {
>> x = y + z;
>> }
>>
>> This gives you two paths to check, one of which involves a calculation.
>>
>> If you add overflow checking, you have this:
>>
>> if (a) {
>> x = y + z;
>> if (overflow) {
>> doSomethingAboutTheOverflow();
>> }
>> }
>
> No no no no no no no!
>
> No.
Yes.
You have to test the code that runs. It doesn't matter if the code
comes directly from /your/ source code, or from the implementation
generating it as hidden tests and jumps. If you have overflow detection
on addition, then "+" can no longer be tested as "add two numbers" - it
must be tested as "add two numbers and perhaps jump around".
>
> No, we're talking about the *implementation* inserting code. Your source
> code does not change *at all*. And you can switch it off.
If you switch it off for the main production code, then that's fine.
You don't need to do the same sort of code-coverage testing for your
debug builds as you do for code that you intend to ship.
> If you're
> concerned that the introduction of the implementation's overflow check
> creates hidden code paths within the object code (and that's a perfectly
> reasonable concern), then here's what you do:
>
> 1) run the tests /without/ overflow checking. 168 hours. Fine,
> everything passed --- keep going as if all is well (because, as far as
> you know, it is), BUT...
> 2) find an old computer that's propping open a door, and set it to
> running the same tests, this time with overflow checking enabled. 169
> hours of electricity, but it's not holding you up. In fact, it *only*
> holds you up if, 169 hours later, it says "BEEP! I found an overflow!"
> in which case you surely do want to know about it.
>
> <snip> - and, in the bit I snipped, you cover some of the above, so I
> think we may be in violent agreement.
>
I think that's the case. Violent agreement is more fun than peaceful
disagreement :-)
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-09 15:52 +0000 |
| Message-ID | <o2ejto$plq$2@dont-email.me> |
| In reply to | #98518 |
On 09/12/16 15:08, David Brown wrote: > On 09/12/16 15:55, Richard Heathfield wrote: <snip> >> >> No, we're talking about the *implementation* inserting code. Your source >> code does not change *at all*. And you can switch it off. > > If you switch it off for the main production code, then that's fine. Just for the avoidance of all doubt, this has always been my position. <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-09 17:35 +0100 |
| Message-ID | <o2emds$5ek$1@dont-email.me> |
| In reply to | #98507 |
Le 09/12/2016 à 15:46, David Brown a écrit :
> In the tests without overflow checking, you have code like this:
>
> if (a) {
> x = y + z;
> }
>
> This gives you two paths to check, one of which involves a calculation.
>
> If you add overflow checking, you have this:
>
> if (a) {
> x = y + z;
> if (overflow) {
> doSomethingAboutTheOverflow();
> }
> }
>
> For every calculation with overflow checking, you have added another
> code path to check. If you have not gone down that path, your tests
> don't have full coverage of the code you have written.
>
> If the action on overflows is all the same - jump to safe mode, deploy
> parachutes and airbags, panic, prey, say your last farewells - then it
> is possible that the testing is feasible if you have some way to
> artificially inject overflows in code that you know cannot possible
> /have/ overflows. But if the action on overflows is a recovery, or an
> exception-type mechanism, then you have hugely multiplied up the number
> of possible code paths in each function. Your cyclomatic complexity
> goes through the roof, and instead of /adding/ an hour to your test, you
> are multiplying it by 2 to the power of the number of calculations in a
> function.
>
Sure, the length of the test has gone up.
SO WHAT?
Compared to the serious consequences of an overflow, making the tests
run for more time doesn't seem (for me) a bad idea.
You seem to imply that because testing for overflow and overflow
handling is difficult, it shouldn't be done.
You are not alone with that idea. At ESA apparently they also had this
very bright idea
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-09 18:35 +0100 |
| Message-ID | <o2epuf$juu$1@dont-email.me> |
| In reply to | #98556 |
On 09/12/16 17:35, jacobnavia wrote:
> Le 09/12/2016 à 15:46, David Brown a écrit :
>
>> In the tests without overflow checking, you have code like this:
>>
>> if (a) {
>> x = y + z;
>> }
>>
>> This gives you two paths to check, one of which involves a calculation.
>>
>> If you add overflow checking, you have this:
>>
>> if (a) {
>> x = y + z;
>> if (overflow) {
>> doSomethingAboutTheOverflow();
>> }
>> }
>>
>> For every calculation with overflow checking, you have added another
>> code path to check. If you have not gone down that path, your tests
>> don't have full coverage of the code you have written.
>>
>> If the action on overflows is all the same - jump to safe mode, deploy
>> parachutes and airbags, panic, prey, say your last farewells - then it
>> is possible that the testing is feasible if you have some way to
>> artificially inject overflows in code that you know cannot possible
>> /have/ overflows. But if the action on overflows is a recovery, or an
>> exception-type mechanism, then you have hugely multiplied up the number
>> of possible code paths in each function. Your cyclomatic complexity
>> goes through the roof, and instead of /adding/ an hour to your test, you
>> are multiplying it by 2 to the power of the number of calculations in a
>> function.
>>
>
> Sure, the length of the test has gone up.
>
> SO WHAT?
Look at what I wrote. The length of the code coverage tests goe up to
the point that the code can no longer be tested through all paths. It's
fine for tests to take a bit longer, or require more computing power to
run. It is /not/ fine for the code to be untestable because of
redundant overflow checks!
>
> Compared to the serious consequences of an overflow, making the tests
> run for more time doesn't seem (for me) a bad idea.
Please understand - overflows are one of a vast number of possible error
causes in programs. They are not a major cause of bugs, or a major
cause of system failures. They are /easily/ avoided in real world code
with just a small bit of knowledge and effort on behalf of the
programmers, code reviewers and testers. For something like spacecraft
control code, I would not expect overflow detection /ever/ to be
triggered even during the earliest tests at the first stages of development.
Having said that, I have repeatedly said that it /does/ make sense to
include some sort of overflow checking while doing development testing -
it is better to have this extra check than not to have it. But this is
a different kind of testing from complete code coverage testing of
production-ready code.
>
> You seem to imply that because testing for overflow and overflow
> handling is difficult, it shouldn't be done.
I am not implying anything, I am stating things outright. Checking for
overflow at runtime when the overflow cannot happen is a /bad/ thing.
It is worse than useless. It adds extra code that has not been fully
tested (as explained above, it cannot be fully tested). That means a
higher risk of errors. And if it detects overflow, it is too late - the
system is already broken.
Checking for overflow during development time /can/ be a useful help in
debugging - though I severely doubt that it would ever catch an error in
such development.
And even though it is always nice to catch errors during development, I
question whether this is an effective use of /your/ time as the
toolchain developer - or whether you would do your users more good by
improving checks for more subtle and more likely bugs, such as memory
leaks or pointer bugs. Your time as a developer is not unlimited - if
your effort spend on adding overflow detection means other more useful
checks are not implemented, then implementing overflow detection has
negative utility for your users.
Now, a little warning. I am going to mention gcc, and also clang. I am
doing so as /examples/, to show how other compiler developers have
prioritised run-time checking of program misbehaviour. This is not
because I think these are the only compilers that matter, or any other
paranoid fantasy you have - it is an example that shows how a great many
people involved in compiler design rate the relevance of certain kinds
of checks. So sit down, take a deep breath, and don't blow your top
again. OK?
In recent years, clang and gcc have both implemented a range of
"sanitizers" designed to help developers spot run-time errors during
development, debugging and testing (but /not/ production-ready code -
the sanitizers have significant efficiency costs). The order in which
these have been implemented have been based on the risk of these bugs
affecting real code, the consequences of these bugs, and to some extent
the ease of implementing the sanitizer. But note that many of the
difficult ones came first - overflow sanitation is easy in comparison.
To my knowledge, the order has been address checking (for out-of-bounds
pointers, use after free, etc.), thread checking (race detection,
deadlocks, etc.), leak detection, then various sorts of undefined
behaviour detection - of which signed integer overflow is one small
check that was far from the first to be implemented.
I don't disagree that overflows can cause problems in buggy code. I
simply disagree with your prioritising of it, which I think is out of
proportion.
However, I am fully aware that this is /your/ compiler you are talking
about - I don't decide anything here. All I have done is recommend that
you think about this, and consider the matter carefully before putting
too much effort into the task. And I also recommend that you drop any
ideas that overflow detection should be standardised in C - even if I
agreed with you, I know it will not happen so there is no point in
getting worked up about it.
>
> You are not alone with that idea. At ESA apparently they also had this
> very bright idea
The Mars lander crash was /not/ caused by overflow, but by incorrect
algorithms.
[toc] | [prev] | [next] | [standalone]
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web