[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14650: coreutils' getlimits fails to represent float limits correctl
From: |
bugdal |
Subject: |
bug#14650: coreutils' getlimits fails to represent float limits correctly |
Date: |
Tue, 18 Jun 2013 02:10:21 -0400 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
I noticed a bug in the getlimits utility's printing of DBL_MAX, etc.
The precision at which the limits are printed is grossly insufficient
to represent the actual limits; if the output is converted back to a
floating point number of the appropriate type, the result will differ
greatly from the actual limit.
The format specifier used for printing these values is is %Le, which
gives 7 decimal digits. The number of digits needed to faithfully
represent the limits varies by type, but a safe fix would be replacing
printf (#TYPE"_MIN=%Le\n", (long double)TYPE##_MIN); \
printf (#TYPE"_MAX=%Le\n", (long double)TYPE##_MAX);
with:
printf (#TYPE"_MIN=%.*Le\n", DECIMAL_DIG, (long double)TYPE##_MIN); \
printf (#TYPE"_MAX=%.*Le\n", DECIMAL_DIG, (long double)TYPE##_MAX);
It would be possible to use appropriate precisions for each type, but
unfortunately I'm not aware of a convenient way to compute the number
of digits needed based on other properties of the type. FLT_DIG and
DBL_DIG are not the correct values for this; they deal with the
opposite round-trip. One solution would be to simply hard-code the
number of digits for float and double when they're IEEE types, and
otherwise use DECIMAL_DIG for all three types (for obscure systems
where float/double are not IEEE single/double). I believe the correct
number of digits for IEEE single or double would be 10 and 17,
respectively.
Rich
- bug#14650: coreutils' getlimits fails to represent float limits correctly,
bugdal <=