Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 3 Jan 2009 14:57:18 +0100
From:      Anton Berezin <tobez@tobez.org>
To:        Fernan Aguero <fernan.aguero@gmail.com>
Cc:        freebsd-perl@freebsd.org
Subject:   Re: Storable byteorder incompatibilities in different FreeBSD installations
Message-ID:  <20090103135718.GC41513@heechee.tobez.org>
In-Reply-To: <520894aa0901030433i7a103ba7i4236ae17b83c6eae@mail.gmail.com>
References:  <520894aa0901020758o79bb1233teee539f6d599d10a@mail.gmail.com> <20090102164439.GF40649@heechee.tobez.org> <520894aa0901030433i7a103ba7i4236ae17b83c6eae@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Fernan,

On Sat, Jan 03, 2009 at 10:33:22AM -0200, Fernan Aguero wrote:

> Apart from the byteorder issue, the other issue which I raised in my
> post, was also the incompatibility in 'longsize' between two perl
> instances built from ports, in different boxes.
> 
> In this case, the perl built in a FBSD-6.3, i386 box has a longsize of
> 4, whereas the same perl built in FBSD-7.1, amd64 has a longsize of 8.
> In both cases they were compiled with PERL_64BITINT (the default for
> the port), and in both cases the byteorder is the same!
> 
> How can I build a perl with a byteorder of 12345678, and a longsize of
> 4, in an amd64 platform? Is that possible at all?

Not really.  Amd64 is a 64-bit platform, meaning sizeof(long) = 8.  I am
pretty positive that the same is true for x86-64 Linux.  That's more or less
what "12345678" indicates.

At any rate, this is the application design issue.  The practical solution
in your case would be to take an offline copy of the DB, and to go through
every record and convert it into a KNOWN to you binary format.  I have not
done the relevant testing, so I do not even know whether nstore() will do
what you want - after all, it only handles the byteorder issues, not integer
size issues.

It is dangerous to make assumptions about bytesizes of various structures on
different architectures - you've got to do some sort of conversion yourself,
"native to known" during the store operation, and "known to native" during
the retrieve operation.

This is just a common sense design principle.

Cheers,
\Anton.
-- 
There is no beauty in entropy. -- Eliezer Yudkowsky



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090103135718.GC41513>