-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Bruno Haible on 4/1/2008 7:05 PM: | While I like that you collected the many instances of the function which | returns a NaN into a single place, I don't like two things here: | | 1) POSIX says that <math.h> defines the macro NAN, but also says that it | expands into a constant expression. We cannot guarantee that. Therefore | is it better to define the macro or not?
Well, I did document in doc/posix-functions/math.texi that NAN might not be constant (so maybe you should update that to mention that NAN should not be used, and point to nan.h instead?) | 2) You make use of this macro also where a 'double' or 'long double' NaN | is expected. We have enough portability problems with 'double' and | 'long double' alone; I'm not inclined to also get trapped by possible | bugs in the conversion from float NaN to 'long double' NaN. But are there any platforms out there that do the (implicit) cast wrong? In other words, I think splitting this into three functions is somewhat of an overkill. But as you've already checked it in, I guess we can live with it. | | 2008-04-01 Bruno Haible <[EMAIL PROTECTED]> | | * tests/test-vasnprintf-posix.c: Include nan.h instead of <math.h>. Were you planning on backing out the math.in.h changes? If so, you must also change strtod.c and test-math.c, if not, it seems like we're being inconsistent. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkfy4kAACgkQ84KuGfSFAYDrjQCglbScUPdLDNSUsiq9cB0tQ88X NlwAoMmodimLM4ZHoyGtYIclWVEsrwfv =kUEG -----END PGP SIGNATURE-----
