[Cfp-interest 2663] Re: GB-287

[Jim Thomas]

This shows that IEEE 754 does not require conversion between hexadecimal strings and decimal formats. But that’s not the rationale for having the strtodN functions accept hexadecimal strings. IEEE 754 5.4.2 does require conversions between all supported floating-point formats. We don’t have any other way of converting from non-arithmetic binary formats to decimal formats without the hexadecimal support in strtodN. Joseph explains the difficulties in [Cfp-interest 2657] Re: GB-287.

- Jim

> On Jan 31, 2023, at 2:24 AM, Mike Cowlishaw <mfc at speleotrove.com> wrote:
> 
>> IEEE 754 requires correctly rounded conversions between all 
>> supported formats (arithmetic and non-arithmetic). Adding the 
>> hexadecimal support completed the required conversions. See 
>> H.4.3 and the example in H.12.2.
> 
> Just to clarify, here, a 'format' in 754, as defined in 754 clause 3, does
> not include "External hexadecimal-significand character sequences" as
> described in 5.12.3.   The "strings in hexadecimal format" phrase -- or
> something like it -- was, I think used prior to the 2008 standard but we
> were careful this century to not use the word format except for the use as
> in clause 3.
> 
> 5.12 does require exact conversions from binary formats to hexadecimal
> strings, but not decimal:
> "Implementations shall provide exact conversions from each supported binary
> format to external character sequences representing numbers with hexadecimal
> digits for the significand, and shall provide conversions back that recover
> the original floating-point representation, except that a signaling NaN
> might be converted to a quiet NaN. See 5.12.1 and 5.12.3 for details."
> 
> So I agree with Fred J. Tydeman, who wrote "there is NO requirement for
> conversions between hexadecimal strings and decimal floating-point objects".
> 
> Mike
> 
>