Date: Thu, 16 Mar 2000 18:00:23 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
cc: djgpp-workers AT delorie DOT com
Subject: Re: Unnormals???
In-Reply-To: <Pine.LNX.4.10.10003161628410.22148-100000@acp3bf>
Message-ID: <Pine.SUN.3.91.1000316175812.5735L-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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
Precedence: bulk


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:
> 
>        quiet   NaN   propagates  through  almost  every  arithmetic
>        operation without raising  an  exception;  a  signaling  NaN
>        generally   raises   an   exception  when  occurring  as  an
>        arithmetic operand.16)

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?

> > I think our move 
> > to mask all FP exceptions in v2.02 and later was in the right direction.
> 
> Invalid operation may be the single one that can be left unmasked, and
> IMHO should.

That's how things were in v2.01.

> There's no way to trigger it in a C program that hasn't
> enacted undefined behaviour before, AFAICS, so we should be on the safe
> side.

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