[Cfp-interest 2657] Re: GB-287

[Joseph Myers]

On Mon, 30 Jan 2023, Vincent Lefevre wrote:

> On 2023-01-29 21:58:05 -0800, Jim Thomas wrote:
> > IEEE 754 requires correctly rounded conversions between all
> > supported formats (arithmetic and non-arithmetic).
> 
> But AFAIK, this does not apply to strings, though adding the
> requirement for strings in C is good for the programmer.
> 
> > Adding the hexadecimal support completed the required conversions.
> > See H.4.3 and the example in H.12.2.
> 
> Concerning the example in H.12.2, couldn't this be done with a cast?

The issue is conversions from non-arithmetic binary interchange formats to 
(arithmetic or non-arithmetic, interchange or extended) decimal formats.

You can't cast a non-arithmetic format; it's strictly an array of bytes, 
which you can convert to strings with the strfromenc functions (or to 
other same-radix interchange formats with encoding-to-encoding functions).

It's possible that such a non-arithmetic binary interchange format is 
wider than any supported arithmetic binary format, so preventing any use 
of a cast without double rounding being involved.  And using the 
strfromenc functions directly to produce decimal strings with the 
appropriate number of digits (then to be converted exactly to the decimal 
format) doesn't work, because converting from binary encodings to strings 
uses the binary rounding mode but the conversion to decimal needs to use 
the decimal rounding mode for convertFormat operations.  (In addition, 
converting directly to decimal strings like that would result in double 
rounding for subnormal results.)  Since there is no standard rounding mode 
/ option in the strfromenc functions to encode a sticky bit in the low 
decimal digit of output, using the strfromenc functions to produce such an 
extra decimal digit with a sticky bit encoded isn't an option either.

In principle using the strfromenc functions to produce decimal output with 
enough extra digits to avoid incorrect results from double rounding would 
work, but determining "enough" is a tricky matter depending on the two 
formats; I don't think the requirements on CR_DECIMAL_DIG are sufficient 
to guarantee the strfromenc functions would produce sufficiently many 
correct decimal digits for this approach to work.

-- 
Joseph S. Myers
joseph at codesourcery.com