On Wed, Jul 18, 2007 at 03:23:50PM +0200, Erwan Lemonnier wrote:
>
> sub showbin {
> print "bin: ".unpack("B70",reverse pack("d",$_[0]))."\n";
> }
>
> my $v1 = "1.73696";
> showbin($v1);
>
> print "connecting\n";
> my $DBC = DBI->connect("dbi:Oracle:$ORASID",$ORAUSR,$ORAPWD,
> { PrintError=>0, AutoCommit=>0 } );
>
> my $v2 = "1.73696";
> showbin($v2);
>
> This code simply opens a connection toward an oracle database. And
> shows the binary representation of the string "1.73696" converted into
> a native float (NV) before and after we opened the connection.
> When I run it with perl 5.6.2, DBI 1.38 and DBD::Oracle 1.17, it says:
>
> [HEAD] ~/HEAD/test/t> !967$ /opt/perl-5.6.2/bin/perl 04_test1.t
> bin: 0011111111111011110010101001011010010001101001110101110011010001
> connecting
> bin: 0011111111111011110010101001011010010001101001110101110011010001
>
> When I run it with perl 5.8.8, DBI 1.58 and DBD::Oracle 1.19, it says:
>
> [HEAD] ~/HEAD/test/t> !969$ /opt/perl-5.8.8/bin/perl 04_test1.t
> bin: 0011111111111011110010101001011010010001101001110101110011010001
> connecting
> bin: 0011111111111011110010101001011010010001101001110101110011010000
Ah, now it's getting interesting! :)
Are the two versions of DBD::Oracle built against the same Oracle
version/installation?
What differences are there in the configuration of the two perl versions?
Take a look at the source for the Perl_sv_2nv() function in sv.c
in the two distributions. Also check for differences in the perl config
items that impact that code.
> See how the least significant bit (last one on the right) changes in
> the last run?
> There we have it. It is what caused the problems I have been spamming
> you all with for the last few days :)
Try it with:
my $v1 = "1.73696";
showbin($v1);
require DBD::Oracle;
my $v2 = "1.73696";
showbin($v2);
> Conclusion: on my host (perl 5.8 etc.), the line:
>
> my $DBC = DBI->connect("dbi:Oracle:$ORASID",$ORAUSR,$ORAPWD,
> { PrintError=>0, AutoCommit=>0 } );
>
> seems to alter the way perl parses the string "1.73696". This later
> resulted in arithmetic errors that looked like floating point related
> issues but were not.
>
> Has anyone any idea of what's happening here????
I know that on Solaris the act of loading the Oracle library (e.g.
libclntsh.so) could suck in other libraries which would cause
subtle side effects.
The particular case I (vagely) recall related to alarm(). Loading the
Oracle library caused the threaded version of alarm() to be loaded and
take precedence. So alarm(0) after loading DBD::Oracle wouldn't cancel
the alarm($timeout) set before loading it. Fun. I don't recall now
if/how that got resolved.
Anyway, I mention it because it seems like this is a similar issue.
Tim.
