[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: %a format in tests-ulc*.c
From: |
Bruno Haible |
Subject: |
Re: %a format in tests-ulc*.c |
Date: |
Sat, 22 Apr 2017 00:58:59 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-72-generic; KDE/5.18.0; x86_64; ; ) |
Hi Paul,
> On 04/19/2017 05:13 AM, Gisle Vanem wrote:
> > With "%.3a %d", I do get the expected "0x1.922p+1 33".
> > So are these tests somewhat gcc-centric or what?
>
> Yes. It looks to me like MSVC-2015 is right and glibc is wrong, at least
> in the sense of acting like standard printf.
I agree that MSVC 14 is right, quoting [1]
"a, A ... if the precision is missing and FLT_RADIX is a power of 2,
then the precision shall be sufficient for an exact representation
of the value"
This sentence gives an implementation the freedom to append as many zeroes as
it wants.
But the number we print is 3.1416015625 = 3217 / 2^10; therefore no rounding
is involved. Why would you consider the expected result "0x1.922p+1" wrong?
Bruno
[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html
- %a format in tests-ulc*.c, Gisle Vanem, 2017/04/19
- Re: %a format in tests-ulc*.c, Paul Eggert, 2017/04/19
- Re: %a format in tests-ulc*.c, Gisle Vanem, 2017/04/20
- Re: %a format in tests-ulc*.c,
Bruno Haible <=
- Re: %a format in tests-ulc*.c, Paul Eggert, 2017/04/22
- Re: %a format in tests-ulc*.c, Bruno Haible, 2017/04/22
- Re: %a format in tests-ulc*.c, Paul Eggert, 2017/04/22
- Re: external floating-point representations, Bruno Haible, 2017/04/22
- Re: external floating-point representations, Paul Eggert, 2017/04/22
Re: %a format in tests-ulc*.c, Bruno Haible, 2017/04/21