dc4d+@andrew.cmu.edu (Darius Clynes) (09/27/89)
It is very important that anyone working with THINK C 4.0 apply
the following change immediately to the file scanf.c, and re-make the
ANSI and other library projects using it.
CAN YOU IMAGINE you input .006 (for example and) it gets converted as
.6 !!!
I am very thankful to Christopher Cox for finding this out, solving
and posting it.
I also think that this rather GROSS error bears repeating for the unlucky
ones who find out (as I did) at an ackward moment in a demonstration!!
Here is a repeat of his posting... with my best wishes to Christopher
Cox.
I don't know if this has been reported, or solved yet:
(and I found this 45 minutes after the package arrived, I wonder
what other bugs are out there?)
Think C 4.0 does not parse some floating point numbers correctly.
The problem lies in scanf.c
-----
case -2:
if (c >= '0' && c <= '9') {
F.valid = TRUE;
if (c != '0' || D.sig[0]) { /* Faulty logic */
if (D.sig[0] < sizeof D.sig - 1)
D.sig[++D.sig[0]] = c;
if (F.dot)
--D.exp;
}
}
else if (c == '.' && !F.dot)
F.dot = TRUE;
-----
This results in zeros immediately following a decimal point being lost.
ie:
0.09503 -> 0.9503
.00564 -> 0.564
F.dot can be set, but D.sig[0] is still 0. This means that any zeros
between the decimal point and the first nonzero digit are thrown away.
-----
case -2:
if (c >= '0' && c <= '9') {
F.valid = TRUE;
if (c != '0' || D.sig[0]) {
if (D.sig[0] < sizeof D.sig - 1)
D.sig[++D.sig[0]] = c;
if (F.dot)
--D.exp;
}
+ else if (F.dot)
+ --D.exp;
}
else if (c == '.' && !F.dot)
F.dot = TRUE;
-----
This time the zero will be included by decrementing the exponent. The
if statement will only be exectuted if (D.sig[0] == NULL && c == '0')
because of the limit of the outer if statement.
I tested this change, and it seems to work well.
Chris
ps. Hay Rich, when are we going to see 32 bit QuickDraw support?
my hacks work, but not that great.