On Fri, 18 Jul 2008 10:28:55 +0200 Marcus Holland-Moritz <mhx-perl@[...].net>  wrote: 

MH>  On 2008-07-17, at 10:11:26 -0500, Ted Zlatanov wrote:

> > Is there a reason the pack "q" template requires 64-bit Perl?  It seems
> > like it should be available (in a simulated, not native form) on 32-bit
> > as well.

MH>  How would you suggest that "simulation" to work?

Ilya mentioned on comp.lang.misc.perl that he has it working as a patch
but doesn't have the original patch (and Google didn't help).  Maybe he
can tell us how he implemented it.  I cc him here just in case.

MH>  The primary problem is that the only way to preserve the
MH>  full resolution of a 64-bit integer on a 32-bit perl is
MH>  to store it as a string. (That's what I'm doing in the
MH>  Convert::Binary::C module.)

MH>  However, as soon as you start using that string in numeric
MH>  context, it will be converted to an IV (integer) or NV
MH>  (float), depending on the value, so you may lose precision.

Well, there's also the BigInt module, which can be used just for that
number if the number is too big for 32 bits, both on pack and on
unpack.  I agree, losing data is a bad outcome.

MH>  This is certainly doable, but I'm not sure whether or not
MH>  that is something we want in the core, as it's not very
MH>  DWIMmy:

MH>    mhx@r2d2 ~ $ perl -MConvert::Binary::C -le'print Convert::Binary::C->new->unpack("long
 long", "aaaaaaaa")'
MH>    7016996765293437281
MH>    mhx@r2d2 ~ $ perl -MConvert::Binary::C -le'printf "%d\n", Convert::Binary::C->new->unp
ack("long long", "aaaaaaaa")'
MH>    -1
MH>    mhx@r2d2 ~ $ perl -MConvert::Binary::C -le'printf "%f\n", Convert::Binary::C->new->unp
ack("long long", "aaaaaaaa")'
MH>    7016996765293437952.000000

I'd ask Ilya to provide the semantics of his patch in this regard.
To me, it makes sense to provide some facility for this and DWIM as long
as it's not a dangerous M :)

Ted