bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new modules 'isnan', 'isnanf', 'isnand'


From: Bruno Haible
Subject: Re: new modules 'isnan', 'isnanf', 'isnand'
Date: Tue, 8 Jul 2008 12:45:28 +0200
User-agent: KMail/1.5.4

Hi Ben,

Ben Pfaff wrote:
> PSPP would like to use the isnan macro portably.  Gnulib, through
> its isnanf-nolibm, isnand-nolibm, and isnanl modules, almost has
> what it needs.  I've written up a change set that adds isnanf and
> isnand modules, which correspond to isnanl, and then builds an
> isnan module on top of them.

Correct, these are exactly the pieces that are missing for complete isnan()
support.

> +     * lib/frexp.c: Use new isnand-nolibm.h instead of isnand.h.
> +     * lib/isfinite.c: Likewise, and isnanf-nolibm.h instead of
> +     isnanf.h.
> +     * lib/signbitd.c: Likewise.
> +     * lib/signbitf.c: Likewise.
> +     * lib/vasnprintf.c: Likewise.

I think this is all right, but it would convince me more fully if you could
send two separate patches:
  1) one patch that renames isnand.h to isnand-nolibm.h and likewise for
     isnanf.h,
  2) one patch that introduces the new modules.

The tricky point is that the *printf-posix replacements must not depend on
libm, because the system's printf() does not require libm and hence programs
don't expect to need to link with -lm just for printf. During testing, this
means that test-vasnprintf-posix must not produce link errors.

> +     * m4/isnanl.h (gl_BUILD_ISNANL): New macro used by gl_FUNC_ISNANL,
> +     gl_FUNC_ISNANL_NO_LIBM, and gl_FUNC_ISNAN.

Typo: that should be m4/isnanl.m4.

Good work, thank you!

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]