GNU bug report logs - #14650
coreutils' getlimits fails to represent float limits correctly

Previous Next

Full log

View this message in rfc822 format

From: bugdal <at> aerifal.cx
To: 14650 <at> debbugs.gnu.org
Subject: bug#14650: coreutils' getlimits fails to represent float limits correctly
Date: Tue, 18 Jun 2013 02:10:21 -0400

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.