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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,56250291936154a0 X-Google-Attributes: gid103376,public From: "Tarjei T. Jensen" Subject: Re: OS Bindings (was: Where is the elusive jump command?) Date: 2000/04/15 Message-ID: <8da01j$62r8@ftp.kvaerner.com>#1/1 X-Deja-AN: 611528043 Content-Transfer-Encoding: 7bit References: <38D771CA.D41AF9B5@port.ac.uk><8bq7ku$mc8$1@nnrp1.deja.com><38E0E723.C39C392@quadruscorp.com><8brfm4$4uc$1@nnrp1.deja.com><8brn4k$p6i$1@slb0.atl.mindspring.net><8brrpj$i04$1@nnrp1.deja.com><38E312F8.78883ACB@icn.siemens.de><8c4rvf$d9k$1@nnrp1.deja.com><2000Apr5.070127.1@eisner><2000Apr6.081305.1@eisner><8ci6vf$r5a$1@nnrp1.deja.com><8ck638$krs3@ftp.kvaerner.com><8cp23c$4gp$1@nnrp1.deja.com><8csjs8$o2p3@ftp.kvaerner.com><8d0su8$bqt$1@nnrp1.deja.com> <8d20bq$o2p4@ftp.kvaerner.com> <8d457u$5n33@ftp.kvaerner.com> <8d9qa8$3ff$1@nnrp1.deja.com> Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Organization: Kv�rner Group IT Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 2000-04-15T00:00:00+00:00 List-Id: Robert Dewar wrote >Tarjei says > >"if you implement n-bit arithmetic, then you must implement >full range unsigned n-bit arithmetic with overflow checking." > >AARGH! the Ada 83 mentality at work again. The mentality that >says, you don't need to implement X, but if you implement X >you must implement Y. Not really. In a general modern computing environment these days it is a perfectly reasonable requirement to be able to handle 64 bit unsigned arithmetic with runtime checking if the compiler supports 64 bits integers. If it only supports 32bit integers, then the requirement stands for 32bit unsigned integers. >I trust that Tarjei understands that it would be a lot of >extra work to implement this new form of checked arithmetic. >The consequence of Tarjei's suggested change might well be >that compilers decide, "oh well, 64-bit integer arithmetic >is too much of a pain anyway", and simply don't do it at all. The problem does not go away. All you have done is scaled it down to 32bit. The general problem persists. And you will have to explain why it would be a lot of extra work if I'm to believe you. And I expect that you should prepare yourself for a similar problem when gnat supports 128 bit integers. >Suppose this "glaring defect" were fixed in the RM. > >Then GNAT would have a lot of extra work to do, maybe we would >do it, but maybe we would simply remove 64-bit arithmetic >completely (actually put it under an extension switch) so it >was not considered part of the core. That would be excellent marketing :-) >We have unsigned 64-bit arithmetic similar to the capabilities >of C (well at least GNU-C) and Java in Ada. Yes, that's not >ideal, and for many applications a range checked 64-bit range >would be better. But please don't let best be the enemy of good. Perhaps it should be possible to do it in stages and still conform. E.g. first be able to specify it, manipulate it and use it in arithmetic expressions. I believe that the requirement is there regardless of how much work it is. As times passes the more it becomes neccessary: Computers do not shrink and files and disks become larger. BTW Where I work we have trouble with 32 bit limits. Our Oracle exports have to go through a compression filter (gzip) because otherwise the file becomes too large for the file system and the export fails. Greetings,