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=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,9ce095aba33fe8d0
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news3.google.com!news.glorb.com!npeer.de.kpn-eurorings.net!rz.uni-karlsruhe.de!news.belwue.de!irazu.switch.ch!news-zh.switch.ch!switch.ch!cernne03.cern.ch!cern.ch!news
From: Maciej Sobczak <no.spam@no.spam.com>
Newsgroups: comp.lang.ada
Subject: Re: Negative float problem
Date: Fri, 04 Nov 2005 10:32:33 +0100
Organization: CERN - European Laboratory for Particle Physics
Message-ID: <dkf9rh$ngp$1@sunnews.cern.ch>
References: <1130351574.313991.229420@g14g2000cwa.googlegroups.com>
 <wccmzkwqabg.fsf@shell01.TheWorld.com> <NI-dnTOLqY64F_3eRVn-uQ@comcast.com>
 <wccmzkvrp6v.fsf@shell01.TheWorld.com> <djqqf5$nhn$1@sunnews.cern.ch>
 <wccoe5bc67l.fsf@shell01.TheWorld.com> <djsnpq$1oa$1@sunnews.cern.ch>
 <roxitrmok2qh.4do9qd40gtju$.dlg@40tude.net> <dk4p4u$f6d$1@sunnews.cern.ch>
 <10mspnley7gzu$.1swtj67sv0ldr$.dlg@40tude.net> <dk7i7b$qpp$1@sunnews.cern.ch>
 <38tcpxwxfigo$.18ysjyp9ml92c$.dlg@40tude.net> <dk811j$cp$1@sunnews.cern.ch>
 <2ybc7t4au7g$.166dxwfrds1so$.dlg@40tude.net> <dk9vel$c00$1@sunnews.cern.ch>
 <18nrnlg9zzl5a.k8rl3ajwauqi.dlg@40tude.net> <dkadfs$g96$1@sunnews.cern.ch>
 <nvhakd.ihb.ln@hunter.axlog.fr> <dkcmjf$pej$1@sunnews.cern.ch>
 <oq2dkd.1a7.ln@hunter.axlog.fr> <dkd8pd$6rd$1@sunnews.cern.ch>
 <82taf.16826$Ul3.8009@trndny07>
NNTP-Posting-Host: abpc10883.cern.ch
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: sunnews.cern.ch 1131096753 24089 (None) 137.138.37.241
X-Complaints-To: news@sunnews.cern.ch
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.7.12) Gecko/20050922 Red Hat/1.7.12-1.1.3.2.SL3
X-Accept-Language: en-us, en
In-Reply-To: <82taf.16826$Ul3.8009@trndny07>
Xref: g2news1.google.com comp.lang.ada:6179
Date: 2005-11-04T10:32:33+01:00
List-Id: <comp.lang.ada>

Frank J. Lhota wrote:

> There are applications, however, where negative integers are divided and 
> remaindered. If such applications are moved to a platform where "/" and 
> "%" are handled differently, portability time bombs are likely to be 
> exposed.

Sure - as with any other "implementation defined" element, in *every* 
language that has them.
If you are worried about the fact that the range of Integer is 
implementation-defined in Ada, don't use it and instead roll your own 
types for whatever domain you are in.
Same for % in C++.

The question what should be implementation defined in the language is a 
valid one, though. If you say that Integer'Range (and sizeof(int)) 
*should* be implementation-defined whereas rem/% should not, I will not 
object.

> Are there any 
> C++ compilers in current use that do NOT round to 0?

I have no idea. As I said - I have not seen any domain where this would 
be of any concern (and actually, you haven't named any neither ;) ).
If it was of any concern, I would certainly define my own types for this 
kind of operations. It is possible to implement them in a way that would 
map to native implementation where they are equivalent.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/