-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Bruno Haible on 5/23/2007 4:10 PM: >>> ASSERT (strlen (result) == 20 + 3 >>> ! && strisnan (result, strspn (result, " "), strlen (result) - 3, 0) >>> && strcmp (result + strlen (result) - 3, " 33") == 0); >> This assertion will fail if the implementation produces an n-char-sequence >> NaN. > > It will fail if the implementation produces an n-char-sequence which is > longer than 15 bytes. Do you find this is likely? If so, feel free to bump > the number 20 to 50 or so.
The only rendition of n-char-sequences that I am familiar with is basically a C-literal integer between the () specifying how the bits within the mantissa portion of the floating point NaN are to be set. Output wise, I've only seen a hex constant, but input wise, gcc's __builtin_nan parses octal and decimal as well. Therefore, on systems where long double is 128 bits (mantissa is 112 bits excluding the implied 1 in normal numbers), a worst-case representation is 5 bytes for nan(), plus 39 bytes for the octal representation with the 112th bit set, plus 1 byte for a sign. So I think you need at least %046f before you can guarantee that the 0 flag was handled correctly on a long double NaN. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGVOIb84KuGfSFAYARAg0tAJ94yK5iAhwY84ZD3yVIesHGJwhQtACfWMzU sUZg7H6QHbHQoEIda0OOQnk= =8G2z -----END PGP SIGNATURE-----
