[Cfp-interest] freestanding

[Joel C. Salomon]

On 02/27/2012 11:45 AM, Jim Thomas wrote:
> On Feb 27, 2012, at 6:21 AM, Stephen Canon wrote:
>> On 02/26/2012 06:20 PM, Jim Thomas wrote:
>>> An ideal specification of strfromf would convert float  to a character sequence directly, without first promoting x to double, as would happen with snprintf. The difference can show up in %a formatting. But such a specification would be a fair amount more complicated. I'm inclined to add strfromf, using the same snprintf definition as for the other two strfrom functions and noting the implicit promotion to double. If it becomes troublesome, we could easily remove it later. What do you think?
>>
>> What I think Jim is getting at is that one might like the %a format specifier to behave differently for single-precision inputs than for double-precision.  Double is 53 bits wide, and the %a format specifier naturally prints normalized double-precision values as 0x1.XXXXXXXXXXXXXpEEEE.  Because 53 = 1 + 13*4, all the bits of the hexadecimal digits have meaning.  However, a single-precision value is only 24 bits wide; converted to a double before printing with %a, you get something of the form 0x1.XXXXXYpEEE, where the low bit of the trailing hexadecimal digit is always zero, so Y can only be 0,2,4,6,8,a,c,e.  Some people would like for strfromf( ) to align the significand against a hexadecimal digit boundary instead, so that values would print as 0xX.XXXXXpEEE.  (Personally, I rather prefer hex floating-point values to start with 0x1., but I can see the other argument).  Of course, if we had strfromf, users could get my preferred behavior by simply calling strfromd instead.
> 
> Yes, this is what I was getting at. The functionality IEEE 754 requires will be there even if we don't have the strfromf function. The reason for having it is that the C library generally provides separate functions for each floating type. 
> 
> If we define strfromf as equivalent to a call to snprintf, then if double values are printed as 0x1.XXXXXXXXXXXXXpEEEE (as they probably are) then float values will necessarily be printed as 0x1.XXXXXYpEEE (or 0x1.XXXXXY0000000pEEE). I don't see this as a major objection. The specification of the strfrom functions is clearly derived from snprintf, which is most obvious in the format argument.

OK, I'm convinced; strfromf can be omitted or defined as a duplicate of
strfromd. [Maybe let's not define it, so an implementation can offer a
float-specific version as an extension?]

I still think that an informative footnote is in order, to the effect
that %a applied to a float will output extra zeros, and that the maximum
meaningful precision for floats is %.6a. (And that the final hex digit
will always be even.)

--Joel