| Re: signed int64 pack/unpack [message #184589 is a reply to message #184588] |
Sun, 12 January 2014 03:15   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 1/11/2014 10:11 PM, Ben Bacarisse wrote:
> Jerry Stuckle <jstucklex(at)attglobal(dot)net> writes:
>
>> On 1/11/2014 9:42 PM, Ben Bacarisse wrote:
>>> cameron7(at)gmail(dot)com writes:
>>>
>>>> I'm having a bit of trouble figuring out a straightforward way to
>>>> "pack" / "unpack" a signed int64.
>>>>
>>>> I'm on a 64-bit machine, but the 'i' and 'I' are coming back with
>>>> 4-byte length.
>>>
>>> There is no explicit format for 64-bit ints. The i/I formats are used
>>> for a native "int" but that need not be 64 bits on a 64-bit machine.
>>> The function is borrowed from Perl whose documentation says a bit more
>>>
>>> This 'integer' is _at_least_ 32 bits wide. Its exact size depends on
>>> what a local C compiler calls 'int'.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> On my 64-bit Linux machine, 'int' is 32 bits.
>>
>> On my 64 bit Linux system, 'int' is 64 bits. But then I have the 64
>> bit PHP version (and 64 bit OS) loaded.
>
> Yes, me too.
>
>> What do you get when you do:
>>
>> <?php
>> echo PHP_INT_MAX . "\n";
>> ?>
>
> Same as you but I don't think that's relevant. PHP stores values
> internally using a C long. I think the Perl document describes what's
> really happening.
>
It is totally relevant. You can't operate on 64 bit values if you don't
have 64 bit support.
And this is PHP, not Perl. Things have changed a *lot* since the
original versions were created. Much of the Perl documentation no
longer applies to PHP (if it ever did).
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]