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,17506301c0751a38
X-Google-Attributes: gid103376,public
From: Matthew Heaney <matthew_heaney@acm.org>
Subject: Re: Need exception despite Machine_Overflows is false
Date: 1998/12/18
Message-ID: <m3hfuttkvv.fsf@mheaney.ni.net>#1/1
X-Deja-AN: 423668099
Sender: matt@mheaney.ni.net
References: <36796140.62B2788C@magic.fr> <ug1ad8kyo.fsf@gsfc.nasa.gov>
NNTP-Posting-Date: Fri, 18 Dec 1998 09:32:53 PDT
Newsgroups: comp.lang.ada
Date: 1998-12-18T00:00:00+00:00
List-Id: <comp.lang.ada>

Stephen Leake <Stephen.Leake@gsfc.nasa.gov> writes:

> Pascal MALAISE <malaise@magic.fr> writes:
> 
> > Using gnat 3.10p on Linux,
> > I make several computations on long_float (s), then use a
> > text_io.float_io
> > to display the results => NaN*****
> > 
> > There is an overflow, Gnat uses the libc, long_float'Machine_Overflows
> > is false...
> > fair enough.
> > 
> > What can I do to get a constraint_error raised when there is an
> > overflow?
> > Don't tell me that I have to check, via an interface to C finite(), the
> > result of
> > each operation!
> 
> You could try adding a range constraint to your basic floating point type:
> 
> type Real is digits 9 range -1.0e307 .. +1.0e307;
> 
> As long as your limits are tighter than the machine limits, the
> compiler will insert explicit checks. Of course, this will slow things
> down, but I assume you could remove the limits after you find the bug.
> 
> This is one reason not to use the predefined Float type!

I think this statement is misleading.

The problem here has nothing to do with the "predefined Float type."
The "problem" is that an unconstrained type was used, when a constrained
type was desired.  You would have the same problems if you did:

  type My_Float is digits 6;

This declares an _unconstrained_ floating point subtype, meaning that no
constraint checks are performed.

Perhaps a better statement would be:

  This is one reason not to use unconstrained floating point subtypes!