-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Eric Blake on 3/14/2007 7:16 AM:
Revisiting this thread with a new question, and adding bug-gnulib to cc... > > When using %a and %A, is it worth tightening the specification to require > the leading hex digit be smaller than FLT_RADIX (under CX shading)? For > example, the current wording allows 1.0 to come out as 0x1.p+0, 0x2.p-1, > 0x4.p-2, or even 0x8.p-3. But it seems like it would be nice to have some > consistency, and require that when FLT_RADIX is 2 (which is often the > case, since most platforms these days use IEEE floating point) and the > number is not denormal, that the leading hex digit should be 1. Bruno Haible pointed out on the gnulib list that if the leading character is less than FLT_RADIX, then depending on the width of the mantissa, a format of %a will never end in an odd digit, whereas allowing implementations to start with a larger digit makes it easier to line up the hex digits in the result to the hex digits of an integer with the same bit pattern. So I guess I will concede leaving the definition loose for now (ie. there are four valid answers for %a on any given normal floating point value). http://lists.gnu.org/archive/html/bug-gnulib/2007-04/msg00092.html However, he also raised the question as to whether "%010f" and "%010a" are supposed to output " inf" (glibc does this) or "0000000inf" (FreeBSD does this). Personally, I think that FreeBSD has a bug in this regard, since I feel it should always be possible for strtod() to be able to correctly reparse the output of %010[aefg], but strtod("0000000inf", NULL) returns 0, not infinity. Note that the rationale for strtod states "The changes to strtod() introduced by the ISO/IEC 9899:1999 standard can alter the behavior of well-formed applications complying with the ISO/IEC 9899:1990 standard... The change in behavior is due to the inclusion of floating-point numbers in hexadecimal notation without requiring that either a decimal point or the binary exponent be present", making it sound like it is intentional for strtod to handle whatever printf can throw at it. But the rationale is non-normative. Do we need an aardvark to tighten up the wording of *printf to guarantee that the 0 flag in printf does not result in leading zeros on infinities and NaNs? http://lists.gnu.org/archive/html/bug-gnulib/2007-04/msg00103.html - -- 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 iD8DBQFGFZSN84KuGfSFAYARAvJwAJ45VVc4ScBClSS6hQbv39Jo2hcM4wCfZSXR xjyr+68Rq1boXrRlJIjxm+k= =F8VE -----END PGP SIGNATURE-----
