Re: printf "%010a" Inf/NaN and FreeBSD

[Bruno Haible]

Eric Blake wrote:
> > I find glibc's output more sensible, since strtod will accept it, while
> > strtod will not grok "0000000inf". But FreeBSD appears to be closer to
> > the POSIX wording, I won't count it as a FreeBSD bug.
> 
> I would, though.  POSIX allows "inf" vs. "infinity", but unless %010f
> prints "0000000inf", I don't think %010a should do so either, because
> POSIX was clear that "A double argument representing an infinity or NaN
> shall be converted in the style of an f or F conversion specifier."

There is also the description of the '0' flag, which says the same for 'a'
as for 'f':
   "For d , i , o , u , x , X , a , A , e , E , f , F , g , and G conversion
    specifiers, leading zeros (following any indication of sign or base) are
    used to pad to the field width; no space padding is performed."

> For that matter, I would really like it if you could guarantee that the
> digit immediately before the . were less than FLT_RADIX.  POSIX doesn't
> require it, but I find it nicer to see 0x1.0p+0 rather than the somewhat
> disconcerting 0x8.0p-3.

POSIX doesn't guarantee it. And on systems where the number of mantissa bits
(including the hidden bit) is not congruent to 1 modulo 4, the printf
implementor might choose to map the bits in a predefined way, i.e. on x86
with 'long double':

        bit 63 .. bit 60 bit 59 .. bit 56 ......... bit 3 .. bit 0
       |                |                |         |              |
           [1-F]        .     [0-F]       .........      [0-F]

If the hex digit before the '.' is guaranteed to be 1, the last hex digit
could never the values 1,3,5,7,9,B,D,F. Which is somewhat unnatural.

Bruno