I take it that ivtype does *not* have to match.
That may be so, but it seems that longsize also has to match - because that's apparently what Storable stipulates(and for no good reason, AFAICT).
On an Ubuntu box using a perl whose ivsize was 8 and byteorder was 12345678, I ran:
use strict;
use warnings;
use Storable;
my $val = 12345678;
my $file = 'store.ubu';
store (\$val, $file);
my $valref = retrieve($file);
print "$val $$valref\n";
Then I copied (via scp) the generated 'store.ubu' over to a Windows box. (The file does not get changed by the transfer.)
Using a compatible Windows perl (ivsize of 8 and byteorder of 12345678) I ran this script to retrieve the value:
use strict;
use warnings;
use Storable;
my $file = 'store.ubu';
print "Retrieving $file\n";
my $r = retrieve($file);
print $$r, "\n";
It output:
Retrieving store.ubu
Long integer size is not compatible at C:/_64/perl522_492/lib/Storable
+.pm line 383, at retrieve.pl line 9.
I then went into the Storable-2.51 source and changed line 6037 of Storable.xs from:
if ((int) *current++ != sizeof(long))
to
if ((int) *current++ != sizeof(IV))
(That's the condition that terminates the script and emits the "Long integer size is not compatible" error message.)
I then rebuilt and installed this modified Storable-2.51 and re-ran the retrieval script. This time I got exactly what (I think) I should have been getting all along:
Retrieving store.ubu
12345678
Storable is actively disabling retrieval when it's not necessary to do that.
Is that the way it's supposed to behave ?
Why is it effectively insisting that longsize be the same - especially given that longsize typically differs between linux and windows ?
Cheers, Rob |