X-Authentication-Warning:	acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date:	Thu, 16 Mar 2000 18:19:27 +0100 (MET)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender:	broeker AT acp3bf
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Unnormals???
In-Reply-To:	<Pine.SUN.3.91.1000316175812.5735L-100000@is>
Message-ID:	<Pine.LNX.4.10.10003161757070.22148-100000@acp3bf>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	dj-admin AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Thu, 16 Mar 2000, Eli Zaretskii wrote:
> On Thu, 16 Mar 2000, Hans-Bernhard Broeker wrote:

> > > I'm not sure it's a good idea to enable FP exceptions.  They make ANSI 
> > > compliance in math functions next to impossible, since AFAIK the standard 
> > > explicitly forbids math functions to crash the program.  
> > 
> > Not so for 'signaling NaNs', I think. Quoting the C99 draft, 
> > section 5.2.4.2.2, paragraph 3:
[...]

> This is not the part of the standard I was worried about.  C89 explicitly 
> required math functions not to crash, but to set errno instead.  What 
> does C99 say about that?

       7.12.1  Treatment of error conditions

       [#1]  The  behavior  of each of the functions in <math.h> is
       specified  for  all  representable  values  of   its   input
       arguments, except where stated otherwise.

This leaves us with the question wether a NaN (signaling or not)
is 'representable value'. Compared to C89, this has been weakened
a bit. There used to be second sentence:

       Each function shall execute as if it were a single operation,
       without generating any externally visible exceptions.

This is no longer there, and there doesn't seem to be a comment in the
Rationale giving a possible reason for that decision. But there is this
paragraph:

  The Standard has been crafted to neither require nor preclude any
  popular floating-point implementation. This principle affects the
  definition of domain error: an implementation may define extra domain
  errors to deal with floating-point arguments such as infinity or
  "not-a-number" (NaN).

To me, this means we're free to do whatever we want if the user passes NaN
or Infinity, to any given function that is not documented to behave in a
defined way, by the standard.

[...]
> I'm not sure what that means.  "sqrt(-1)" produces the invalid operation 
> exception.

Ooops, my fault, I forgot to read on to the next page, where other
sources of invalid operation SIGFPE were listed...

Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -