There is a small program and generate the different result on 6.1 and 6.2. This is the small program: main() { int decpnt, neg; printf("%s\n", fcvt(19.0, 16, &decpnt, &neg)); printf("%d\n", decpnt); printf("%s\n", fcvt(322.45, 16, &decpnt, &neg)); printf("%d\n", decpnt); printf("%s\n", fcvt(9.44, 16, &decpnt, &neg)); printf("%d\n", decpnt); printf("%s\n", fcvt(9.0, 16, &decpnt, &neg)); printf("%d\n", decpnt); } On 6.2, when build and run, the output is: 190000000000000000 2 322.449999999999988 2 94399999999999995 1 90000000000000000 1 when build on 6.1 and run it, the output is : 190000000000000000 2 322449999999999988 3 94399999999999995 1 90000000000000000 1 Looks like the fcvt() has some problem on 6.2. We notice that one of the library called "glibc" has the different version on 61 and 62, the one on 61 has the version: 2.1.2., and on 6.2 it is 2.1.3. If we install the old version (2.1.2) on 62, then the problem disappears. Jianhua 303-294-4775
I've mailed a patch for this at http://sources.redhat.com/ml/libc-hacker/2000-12/msg00039.html Am now waiting for feedback from other glibc hackers.
Do you think i can able to get the patch and put on my machine to test someday?
Fixed in glibc-2.2-9 errata (together with other fixes). As this problem is not severe enough to justify errata for older glibcs, there won't be any errata for glibc-2.1.x because of this. Use fcvt_r if you're building programs against older libcs (and pass a sufficiently large buffer to it). Or you can use sprintf and memmove the decimal dot out...
I cannot find any manual for fcvt_r(). I can use ecvt(), but it is a little different. I can use gcvt(), sprintf(), then the logical is changed, i have to mantain the result by by myself, so for our database product, i don't think it is a good way to make these kind of change, because this is means, everywhere we called the fcvt(), we need free the memory sometime after, but previously, we don't need do that. So we cannot say, this problem is not important.