Date: Thu, 23 Apr 1998 17:25:58 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Paul Derbyshire <pderbysh AT usa DOT net>
cc: djgpp AT delorie DOT com
Subject: Re: Spotting NaNs
In-Reply-To: <353F141B.24547B62@usa.net>
Message-ID: <Pine.SUN.3.91.980423171834.10966G-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Thu, 23 Apr 1998, Paul Derbyshire wrote:

> I also noticed neither isnan() nor isnanf() appear to be ANSI or POSIX. Are they
> widely supported? Or a Gnu extension? or...?

They are neither ANSI nor Posix (look inside math.h and observe that 
their prototypes are after both __STRICT_ANSI__ and __POSIX_SOURCE).  
They are compatible with Unix BSD systems, and therefore many Unix 
systems, including Linux, support them as well.  But DOS and Windows 
compilers is another matter (e.g. Borland doesn't have them).

> Is there a #define that will
> indicate whether they exist? this way I can conditionally compile a header of
> mine to use them if they exist, or else use mine.

AFAIK, you cannot use a pre-processor symbol to inquire about these
functions.  In fact, with a few exceptions, you cannot infer about
existence of any function using pre-processor definitions.  That is why
GNU invented the configure script.  It solves this problem by compiling a
small test program that calls the function and looking at the exit code of
the linker.  If the linker fails, it means the function is not available,
so the script either adds a #define HAVE_ISNAN 1 or #undef HAVE_ISNAN to a
local header file which is used by the package when it is built.