On 2024-09-12 01:20, Paul Zimmermann wrote:
> Hi Brian,
>
>>> $ gcc test_printf.c /localdisk/zimmerma/newlib-4.4.0.20231231/build/x86_64/newlib/libm.a
>>> $ ./a.out
>>> x=0.9694811147877118 upward:0.969481
>>>
>>> Is that a known issue?
>>
>> Is that not only a requirement of IEEE arithmetic operations?
>> Is that also an expected requirement of *printf?
>
> the C standard [1] writes on page 511:
>
> 15 The binding for the convertFormat operation applies to all conversions among IEC 60559 formats.
> Therefore, for implementations that conform to Annex F, conversions between decimal floating types
> and standard floating types with IEC 60559 formats are correctly rounded and raise floating-point
> exceptions as specified in IEC 60559.
Those are references to IEC/IEEE 60559 BFP binary and DFP decimal FPU formats in
F.3 Operations.
> [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf
N3301 is C203Y WD with final C2024 text plus a few new changes: F3. Operations
para.15 p.534.
GCC float.h sets FLT_ROUNDS 1 and CR_DECIMAL_DIG to UINTMAX_MAX, and says it
follows *C99* Annex F except where it says results depend on the standard
library implementation.
The newlib and glibc standard I/O libraries say only correctly rounded, and some
limits on correctly rounded digits, but say nothing about Annex F or IEC/IEEE
60559.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.