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: 
 border1.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!1.eu.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!eternal-september.org!feeder.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 14:53:59 +0200
Organization: A noiseless patient Spider
Message-ID: <mi7q38$lge$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>
 <mi7kvr$3j0$1@dont-email.me> <x6ylsamkw1s1$.oijdzulh0l8s.dlg@40tude.net>
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 12:52:56 +0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="b96887e80893c84a90c3007226ca0d1c";
 logging-data="22030"; mail-complaints-to="abuse@eternal-september.org";
 posting-account="U2FsdGVkX1+BqPOfBsEjGaV6P8B9aUy1ChXHYKMYoUY="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:31.0) Gecko/20100101 Thunderbird/31.6.0
In-Reply-To: <x6ylsamkw1s1$.oijdzulh0l8s.dlg@40tude.net>
Cancel-Lock: sha1:PDKS2GFDNHi0wspbzKWEgmM6IAk=
Xref: number.nntp.giganews.com comp.lang.ada:193033
Date: 2015-05-04T14:53:59+02:00
List-Id: <comp.lang.ada>

On 04.05.15 14:17, Dmitry A. Kazakov wrote:
> On Mon, 04 May 2015 13:26:50 +0200, G.B. wrote:
>
>> On 04.05.15 10:45, robin.vowels@gmail.com wrote:
>
>>> Detecting overflow is typically very fast.
>>
>> Is it fast?
>
> It is not trivial to handle hardware counter's overflows, e.g. by extending
> it, like 32->64, a lot of ugly issues with race conditions.

I thought so, in particular remembering your use of 64 bit FPT
words in non-sequential 32 bit programs? Yet, I think that one
cannot simply assess the complexity of handlers or simply
dismiss using components of larger (sums of) bit sizes
by invoking ceteris paribus.  That would be like assuming
the system to have FPT hardware, and also permission to use it.

Which is why it seems good if a language design does address
the handling of overflow and atomic operations, even if only
in basic ways.

> As a programmer I always suggest to scrap garbage hardware. Engineers
> usually propose the opposite - to fix hardware by software means. That is
> how people get hurt! (:-()

One more argument in favor of clarifying the word "system":
the result of human thought. Again, the problem turns out
to be one of goal directed organization of units of industry.

An error handler achieving that would quite good, wouldn't it?