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
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, 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.

- Raw text -