comp.lang.ada
 help / color / mirror / Atom feed
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: Boeing 787 integer overflow
Date: Mon, 04 May 2015 13:26:50 +0200
Date: 2015-05-04T13:26:50+02:00	[thread overview]
Message-ID: <mi7kvr$3j0$1@dont-email.me> (raw)
In-Reply-To: <535fc0ec-ed85-4f21-8afa-0430e34be383@googlegroups.com>

On 04.05.15 10:45, robin.vowels@gmail.com wrote:

>>> 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.

It doesn't handle the error, if it is one, hence the report.

> Detecting overflow is typically very fast.

Is it fast? The GNAT UG explains overflow handling options
at length, and its default choice of not handling
all overflowing integer computations.

> On some systems,

For the system at hand, we'd have to know what overflow
handling means here, in terms of cost.


>> 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).

If this processor is not one with dedicated overflow
checking support, and efficient at that, then using
two words instead of one for the counting variable
might actually be faster than any overflow handlers.

> Merely using more bits in a register [even if permitted
> by hardware] is not the solution.  It merely defers it.

More bits (64 instead of 32) is a solution, since "deferred"
is then equivalent to "never", as Peter Chapin has explained
when using "ridiculous" for times far into the future, I think.

> The solution is to fix the software, by handling the interrupt
> with a different error handler from the general one.

That's a rephrasing of the original claim. But how to handle?

> An alternative might be to initialize the timer automatically
> before every take-off.

Might it? Is this a known possibility?

Generalizing: some counting variables should _never_ be
re-initialized without accounting: aging parameters would
be restored to "good" by an error in bureaucracy.


  reply	other threads:[~2015-05-04 11:26 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-02 23:34 Boeing 787 integer overflow Robert Love
2015-05-03 11:23 ` Maciej Sobczak
2015-05-03 15:27   ` Georg Bauhaus
2015-05-03 16:03   ` Peter Chapin
2015-05-03 23:34     ` Dennis Lee Bieber
2015-05-04  0:00       ` robin.vowels
2015-05-04  0:38       ` Jeffrey R. Carter
2015-05-04  1:55         ` robin.vowels
2015-05-03 23:54     ` robin.vowels
2015-05-04  8:28       ` Georg Bauhaus
2015-05-04  8:45         ` robin.vowels
2015-05-04 11:26           ` G.B. [this message]
2015-05-04 12:17             ` Dmitry A. Kazakov
2015-05-04 12:53               ` G.B.
2015-05-04 13:28         ` Dennis Lee Bieber
2015-05-03 23:49   ` robin.vowels
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox