Hi all! I have started a thread on perl5-porters discussing the same issue. The posts are not yet archived on http://www.nntp.perl.org/group/perl.perl5.porters/ but should appear there quite soon.
What this new thread boils down to (so far) is that perl 5.6 uses the native atof to convert from string to float, and this atof in its turn save, alter then restore the FPU flags that tells the microprocessor's FPU which rounding mode it should use when computing a significand. Perl 5.8 on the other hand uses its own implementation of atof, a function called Perl_my_atof2 located in numeric.c. This implementation does not alter the FPU flags. Apparently, one of the oracle libraries (or at least something executed when doing DBI->connect) changes the FPU flags and does not restore them afterward. Hence the change in behavior we observed. Now, part of what I just explained are still just hypothesis, but I am getting pretty sure that it's what's happening. A quick work around consists in recompiling perl 5.8 with the cc/gcc flag "-DUSE_PERL_ATOF=0". The new perl binary obtained in that way uses the system's atof and the string-to-float conversion is not altered anymore by whatever happens during DBI->connect: [HEAD] ~/HEAD/test/t> !1086$ /opt/perl-5.8.8_native_atof/bin/perl 01_test1.t 0 01111111111 1011110010101001011010010001101001110101110011010001 connecting 0 01111111111 1011110010101001011010010001101001110101110011010001 Voila! That being said, we have a few possibilities: - restore the FPU flags to the expected default after doing DBI->connect. But it's probably a bad idea since there probably is a good reason why those flags needed to be altered in the first place. - patch perl's Perl_my_atof2 to act as the native atof with respect to FPU flags. That may be a bad idea as well, since it means altering the behavior of perl 5.8. /Erwan
