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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: "G.B." <bauhaus@futureapps.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Boeing 787 integer overflow
Date: Mon, 04 May 2015 13:26:50 +0200
Organization: A noiseless patient Spider
Message-ID: <mi7kvr$3j0$1@dont-email.me>
References: <201505021834588468-rblove@airmailnet>
 <9f20f713-d65c-471d-ab7c-d314a14fdcd0@googlegroups.com>
 <alpine.CYG.2.11.1505031156210.3716@WIL414CHAPIN.vtc.vsc.edu>
 <3e8a4ac6-b0cd-445d-8e9c-82ce8f7f9fee@googlegroups.com>
 <mi7aic$fg$1@dont-email.me>
 <535fc0ec-ed85-4f21-8afa-0430e34be383@googlegroups.com>
Reply-To: nonlegitur@futureapps.de
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 4 May 2015 11:25:47 +0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="b96887e80893c84a90c3007226ca0d1c";
	logging-data="3680"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19H/SWnACPlSwEgYCOil8Oqvx3sKSv5saY="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:31.0) Gecko/20100101 Thunderbird/31.6.0
In-Reply-To: <535fc0ec-ed85-4f21-8afa-0430e34be383@googlegroups.com>
Cancel-Lock: sha1:uk9FziVu5P/3yxZQTEz5aRXc9hs=
Xref: news.eternal-september.org comp.lang.ada:25725
Date: 2015-05-04T13:26:50+02:00
List-Id: <comp.lang.ada>

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.