Ping.
If this is the wrong list for this question, please point me to the right one.
(Btw, in my original post below, I neglected to mention the glibc version used
to prepare the C example. It was glibc 2.35.)
Thanks,
Glenn
On Sun, Apr 10, 2022, at 08:25, Glenn Golden wrote:
> In coreutils 9.0:
>
> $ /usr/bin/printf "%a\n" 0x1.0000000000001p-20
> 0x8.0000000000008p-23
>
> $ c_printf 0x1.0000000000001p-20 # printf("%a\n", strtod(argv[1], NULL));
> 0x1.0000000000001p-20
>
> Imo, this normalization inconsistency is worth addressing. What do you
> think?
>
> There's nothing numerically wrong with either; both emitted strings hew
> to C99 (which allows any nonzero leading hex digit for normal values).
> But still... it would sure be nice (and helpful for testing) if they
> behaved identically so that direct string comparisons could be done.
>
> As a 2c aside from the consistency issue itself: If there is a willingness
> to consistentize them, the approach used by printf(3) seems to me to be
> preferable because it has the nice readily-interpretable semantic that the
> leading hex digit (prior to the radix point) is the implied normalization
> indicator, i.e. either 0 or 1. So you can tell right off the bat whether the
> value is subnormal or not. Nice feature for humans. Admittedly, that
> choice is somewhat IEEE-754-double centric, but given its ubiquity, it doesn't
> seem unreasonable to favor that approach if there's a decision to
> consistentize
> between them.
>
> (Probably this topic has been previously discussed on the list, but could not
> quickly find the thread. If it has been, and you can point me to it, I'll
> educate myself on the background and history.)
>
> Thanks,
>
> Glenn
