Date:	Mon, 20 Mar 2000 19:26:33 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Dieter Buerssner <buers AT gmx DOT de>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Unnormals???
In-Reply-To:	<200003201722.TAA27859@is.elta.co.il>
Message-ID:	<Pine.SUN.3.91.1000320192330.27773D-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 Mon, 20 Mar 2000, Dieter Buerssner wrote:

> What speaks against something like:
> 
> /* Unportable, but should be save for DJGPP */
> #define ld(x) ((long double)(*(long double *)(x))) 
> 
> static const unsigned short pos_nanshort[] = {0,0,0,1,0x7fff,0};
> static const unsigned short neg_nanshort[] = {0,0,0,1,0xffff,0};

Did you try this?  latest versions of GCC play dirty tricks with such 
special patterns, when compiled with -O2.  See the comments in the source 
of nan() and nanf() in libm, for some examples.

>  /* ... */ 
>  /* if domain error: return nan */
>  return zero1/zero; 
>  /* ... */
> }
> 
> The last example even has the advantage, that it can trigger a 
> floating point exception (when unmasked, as may be advisable when 
> debugging, especially when the code is not prepared to handle
> NaNs).

I'm still unsure what does C99 say about math functions raising 
exceptions.

But I don't understand why did you say exceptions are advisable under a 
debugger: in DJGPP versions of debuggers it is actually the other way 
around.

- Raw text -