Re: *printf questions

[Eric Blake]

-----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             address@hidden
-----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-----