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
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: 64-bit unsigned integer?
Date: Wed, 28 Feb 2018 11:59:06 +0100
Organization: Aioe.org NNTP Server
Message-ID: <p7621q$1mlk$1@gioia.aioe.org>
References: <e8c6d243-b919-4fc5-a6dc-aeb5e2042be9@googlegroups.com>
 <421d1598-68d7-4d0b-b596-6e9c59cf865c@googlegroups.com>
 <a0147c10-775c-49bf-a0e7-2091f31ac11a@googlegroups.com>
 <p724lq$2na$1@franka.jacob-sparre.dk> <877eqxe7u8.fsf@nightsong.com>
 <p760ss$1kfl$1@gioia.aioe.org>
NNTP-Posting-Host: MyFhHs417jM9AgzRpXn7yg.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.6.0
Content-Language: en-US
X-Notice: Filtered by postfilter v. 0.8.3
Xref: reader02.eternal-september.org comp.lang.ada:50704
Date: 2018-02-28T11:59:06+01:00
List-Id: <comp.lang.ada>

On 28/02/2018 11:39, J-P. Rosen wrote:
> Le 28/02/2018 à 11:17, Paul Rubin a écrit :
>> Having an unsigned int type that 1) uses all the bits in the machine
>> word, and 2) errors on overflow, plus a separd Word type that wraps
>> around, seems like the right way to do things.  Oh well.
> That would certainly raise many issues. For example, this type would
> certainly not have a unary minus... and if a negative result is found in
> intermediate calculations, C_E should be raised.
> 
> Totally different arithmetic => a new kind of integer type. Just for the
> sake of a single (albeit important sometimes) use case.

On top of that, I think that overflow check in this and similar cases is 
not a problem but a solution born out of necessity. Actually, required 
is absence of overflows, not catching them at run-time. Thus a 
combination of SPARK and a 64-bit modular type could be a far better 
approach.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de