| Re: signed int64 pack/unpack [message #184594 is a reply to message #184592] |
Sun, 12 January 2014 15:51   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 1/12/2014 7:37 AM, Ben Bacarisse wrote:
> Jerry Stuckle <jstucklex(at)attglobal(dot)net> writes:
>
>> 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.
>
> The Perl documentation seems to describe what's happening. The PHP
> documentation leaves the nature of the integer of "machine dependent
> size" unspecified so some clarification is helpful.
>
> 64 bit support may be necessary but it seems not to be sufficient. Many
> 64 systems leave C's "int" as 32 bits, so if pack is still doing what
> the Perl version describes, it's at least an explanation of what's
> happening.
>
>> 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).
>
> I am sure that's true, but, other than the source, I don't think there
> is much more to go on. What is your explanation of what's going on?
>
You can argue, or you can answer our questions and get help.
I see you've already got the answers and all you want to do is argue.
Sorry I wasted my time and the network's bandwidth trying to help you.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]