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-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,57d25404e12d2837
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2002-02-02 14:56:20 PST
Path: archiver1.google.com!postnews1.google.com!not-for-mail
From: dewar@gnat.com (Robert Dewar)
Newsgroups: comp.lang.ada
Subject: Re: How to catch NaNs with gnat3.14p
Date: 2 Feb 2002 14:56:20 -0800
Organization: http://groups.google.com/
Message-ID: <5ee5b646.0202021456.766b2491@posting.google.com>
References: <a3e6eb$2jt$1@nets3.rz.RWTH-Aachen.DE>
 <slrna5l92d.786.randhol+abuse@kiuk0156.chembio.ntnu.no>
 <5ee5b646.0202012220.64dd228f@posting.google.com>
 <slrna5nrk4.nc.randhol+abuse@kiuk0152.chembio.ntnu.no>
NNTP-Posting-Host: 205.232.38.244
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1012690580 10648 127.0.0.1 (2 Feb 2002 22:56:20
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: 2 Feb 2002 22:56:20 GMT
Xref: archiver1.google.com comp.lang.ada:19541
Date: 2002-02-02T22:56:20+00:00
List-Id: <comp.lang.ada>

Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrna5nrk4.nc.randhol+abuse@kiuk0152.chembio.ntnu.no>
 
> And then I included the snip from the User Guide which clearly states
> that the overflow is not checked for floats in 3.13p so if the User
> Guide says the same in 3.14p it must mean that there isn't any overflow
> checks in 3.14p for floats either.


Yes that is completely true and accurate, but that is a totally
irrelevant red herring for this particular
thread which is about range checks, not about overflow checks. Range
checks for constrained floating-point types
work perfectly well in GNAT, and as documented, these
range checks will catch NaN's.

So my objection here was that the entire discussion of
overflow checks is irrelevant. The fact that Machine_Overflows is
false has nothing whatever to do
with range checks, which must of course work properly
for all constrained floating-point types regardless of
the setting of Machine_Overflows.

The point is that "work properly" is not defined for invalid data like
NaN's, where the behavior is implementation dependent. What GNAT 3.14
has done is
to define this implementation dependent behavior to
say that a NaN always looks out of range in a range test.