Subject: coreutils' getlimits fails to represent float limits correctly
From: [email-masked]
To: [email-masked]
Date: Tue, 18 Jun 2013 02:10:21 -0400
List-Id: <debbugs-submit.debbugs.gnu.org>

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