Message-Id: <200003201725.MAA25357@delorie.com>
From: "Dieter Buerssner" <buers AT gmx DOT de>
To: djgpp-workers AT delorie DOT com
Date: Mon, 20 Mar 2000 18:26:03 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Unnormals???
CC: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
References: <Pine DOT LNX DOT 4 DOT 10 DOT 10003201648450 DOT 25247-100000 AT acp3bf>
In-reply-to: <Pine.SUN.3.91.1000320181300.26722I-100000@is>
X-mailer: Pegasus Mail for Win32 (v3.12b)
Reply-To: djgpp-workers AT delorie DOT com

On 20 Mar 00 Eli Zaretskii wrote:

[Putting NANs if FPU registers]

> In assembly, yes.  That's what Eric Rudd did all the way in his math
> functions, so we *know* it's possible.
> 
> But I was thinking about C, not about assembly.

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};

#define POS_NAN ld(pos_nanshort)
#define NEG_NAN ld(neg_nanshort)

nan = POS_NAN;

or even portable to IEEE;

long double zero = 0.0; /* global to avoid faulty optimization */
long double zero1 = 0.0;

long double foo()
{
 /* ... */ 
 /* 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).

Regards,
Dieter