From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.140.132.73 with SMTP id 70mr39036830qhe.6.1430729158013; Mon, 04 May 2015 01:45:58 -0700 (PDT) X-Received: by 10.50.7.101 with SMTP id i5mr123142iga.15.1430729157977; Mon, 04 May 2015 01:45:57 -0700 (PDT) Path: buffer2.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!z60no4935659qgd.0!news-out.google.com!n7ni24511igk.0!nntp.google.com!l13no13576637iga.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 4 May 2015 01:45:57 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=123.2.70.40; posting-account=S_MdrwoAAAD7T2pxG2e393dk6y0tc0Le NNTP-Posting-Host: 123.2.70.40 References: <201505021834588468-rblove@airmailnet> <9f20f713-d65c-471d-ab7c-d314a14fdcd0@googlegroups.com> <3e8a4ac6-b0cd-445d-8e9c-82ce8f7f9fee@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <535fc0ec-ed85-4f21-8afa-0430e34be383@googlegroups.com> Subject: Re: Boeing 787 integer overflow From: robin.vowels@gmail.com Injection-Date: Mon, 04 May 2015 08:45:57 +0000 Content-Type: text/plain; charset=ISO-8859-1 Xref: number.nntp.giganews.com comp.lang.ada:193028 Date: 2015-05-04T01:45:57-07:00 List-Id: On Monday, May 4, 2015 at 6:29:00 PM UTC+10, Georg Bauhaus wrote: > On 04.05.15 01:54, r.nospam@gmail.com wrote: > >> A software fix might be nice, such as increasing the counter to 64 bits to > >> >push the overflow time out to something ridiculous, > > That isn't the solution. > > The solution is to have an appropriate error handler. > > If the variable has system-wide effects, I think error > handling would require a little more than a few lines of > code for overflow. Also provided that detecting overflow can > be made fast enough in the first place. Apparently there is already an error handler. Detecting overflow is typically very fast. On some systems, detection is automatic by hardware while on others, an instruction is executed following the relevant arithmetic operation, to raise an interrupt should overflow occur. > So, if the bit size could be increased without affecting > the system in other ways, this looks like a much cheaper > solution to me. Might not be possible. Dedicated processors have limits on the size of a word, or size of the arithmetic register(s). Merely using more bits in a register [even if permitted by hardware] is not the solution. It merely defers it. The solution is to fix the software, by handling the interrupt with a different error handler from the general one. An alternative might be to initialize the timer automatically before every take-off.