Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!selfless.tophat.at!news.glorb.com!news-in-01.newsfeed.easynews.com!easynews!core-easynews-01!easynews.com!en-nntp-03.dc1.easynews.com.POSTED!not-for-mail From: Robert Wessel Newsgroups: comp.lang.java.programmer,comp.lang.c Subject: Re: Arithmetic overflow checking Message-ID: References: <36bp17tf79bhbd6hovf9srhmcs1jh1c040@4ax.com> <693db00d-83be-4830-a1fc-262d9d34d672@z15g2000pre.googlegroups.com> <9d33ce51-1f6a-4782-8098-a051456532ca@m6g2000prh.googlegroups.com> <8vlr17d90u9cb63hf64hhstaoamdgsb5je@4ax.com> X-Newsreader: Forte Agent 6.00/32.1186 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 45 X-Complaints-To: abuse@easynews.com Organization: Forte Inc. http://www.forteinc.com/apn/ X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly. Date: Thu, 14 Jul 2011 21:10:50 -0500 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:6197 comp.lang.c:8290 On Wed, 13 Jul 2011 13:41:51 -0700, Keith Thompson wrote: >markspace <-@.> writes: >> On 7/13/2011 12:16 PM, lewbloch wrote: >>> The lesson I derive is that nothing is too simple, trivial or obvious >>> to overlook. >> >> >> What I got from reading that is that the root problem was that the range >> of values that the sensor was capable of producing was not understood. >> Either or both physically producing, or would produce under normal (or >> abnormal) system operation. > >As I recall, the range of values the sensor was capable of producing was >understood correctly *when the code was written*. > >The problem is that the code was written for the Ariane 4. Management >decided to re-use the same code, with no modifications, on the Ariane 5 >-- on which the valid range of values from the sensor was quite >different. > >> It was a failure to understand the the design, and its parameters. That >> failure of understanding was then propagated down to the code level. >> "We don't need to protect this because an out of range can't happen." > >Decisions had to be made when the code was written about which >exceptions to handle, and which to assume couldn't happen. >Handling them all wasn't an option because it would have slowed >down the system enough so it wouldn't work at all. The particular >decisions were correct for Ariane 4. In a sense it's not that the exception was unhandled, but rather that the exception was handled as a hardware failure, leading to the shutdown of the inertial guidance computer. Of course the backup guidance system keeled over at the same time (IIRC, the backup system may have actually tripped off first by a few ms). So the problem was not so much the unhandled exception, but the generation of the exception for the normal condition in the first place. The real head-banger is that the code in question no longer did anything useful on the Ariane 5.