Re: Boeing 787 integer overflow

["G.B." <bauhaus@futureapps.invalid>]

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?