Date: Fri, 12 Jan 2001 13:45:40 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: "Tanes Sriviroolchai" <Tanes DOT Sriviroolchai AT Thailand DOT NCR DOT COM>
Message-Id: <6480-Fri12Jan2001134540+0200-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6
CC: djgpp AT delorie DOT com
In-reply-to: <3a5e8f24$1@rpc1284.daytonoh.ncr.com>
	(Tanes DOT Sriviroolchai AT Thailand DOT NCR DOT COM)
Subject: Re: Weird results of log( -1.0 ) with libm.a and without libm.a
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1010111191648 DOT 20014A-100000 AT is> <3a5e8f24$1 AT rpc1284 DOT daytonoh DOT ncr DOT com>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: "Tanes Sriviroolchai" <Tanes DOT Sriviroolchai AT Thailand DOT NCR DOT COM>
> Newsgroups: comp.os.msdos.djgpp
> Date: Fri, 12 Jan 2001 11:58:39 +0700
> 
>     Thanks for your reply. Could you please tell me the reason behind the
> different behavior of log() in libc.a and log() in libm.a.

They were written by different people with different preferences.
libc.a generally follows the FPU design, so it is IEEE-compliant.  In
contrast, libm.a is by default compliant with the X/Open standard.  (I
showed in one of the messages how to get IEEE compliance with libm.a
as well.)

In general, log(-1) might return either NaN or -Inf on other systems
as well (e.g., see the Solaris man page), so it is implementation-
dependent, and your programs should not depend on the value.  The
latest C standard doesn't say a word about the return value in this
case, it just says that ``errno may be set to EDOM'' (note the
``maybe'' part).

> I'm very curious about this. I have checked other systems e.g. SVR4 (NCR),
> Linux, and FreeBSD (I know it cannot be referenced directly) and I see man
> page of SVR4 (NCR) saying that the return is -HUGE_VAL. However, when I use
> isnan() on these systems, all systems give me TRUE as a result (also isinf()
> or other equivalent function return FALSE) and printf() showing it is NaN.

That sounds like some kind of bug, either in the docs or in the isnan
function: it should only return non-zero for a NaN, not for an Inf.

You should be able to look at the bit pattern of the result and
compare it with NaN and Inf, if you don't believe isnan.