Bug#172562: Further information

[Simon Tatham <anakin@pobox.com>]

I've just encountered this problem myself, and I have some more
information and a partial diagnosis.

Attached is a demonstration program which attempts to parse five hex
floats which should be very similar. When I run it, the output is

9215.5
9215.75
144         [ should be 9216 ]
9216.25
9216.5

In other words, it's the _trailing zeros_ that are causing the
problem, and further experimentation suggests that each trailing
zero on the mantissa part increases the output exponent by 1 rather
than by 4.

Therefore I suspect this is a simple oversight when converting the
base-10 code; in base 10, of course, you _do_ have to increase the
exponent by one power of 10 when you take a trailing zero off the
mantissa string.

Attached is a simple patch against the glibc 2.2.5 sources which
causes my demonstration program to start working. (I'm not confident
it's a complete and correct fix, but it's an additional data point
at least.)

Cheers,
Simon
-- 
Simon Tatham         "_shin_, n. An ingenious device for
<anakin@pobox.com>    finding tables and chairs in the dark."

#include <stdio.h>
#include <assert.h>

#define lenof(x) ( sizeof((x)) / sizeof(*(x)) )

int main(void)
{
    static char const *const strings[] = {
        "0x8ffe.p-2",
        "0x8fff.p-2",
        "0x9000.p-2",
        "0x9001.p-2",
        "0x9002.p-2",
    };

    int i, ret;
    double d;

    for (i = 0; i < lenof(strings); i++) {
        ret = sscanf(strings[i], "%lg", &d);
        assert(ret == 1);
        printf("%g\n", d);
    }

    return 0;
}

--- strtod.c.orig	Tue Nov  4 15:23:20 2003
+++ strtod.c	Tue Nov  4 15:23:42 2003
@@ -885,7 +885,7 @@
 	--expp;
 	--dig_no;
 	--int_no;
-	++exponent;
+	exponent += (base == 16 ? 4 : 1);
       }
     while (dig_no > 0 && exponent < 0);