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