Mail Archives: djgpp/2001/01/12/06:48:32
> 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.
- Raw text -