| Re: signed int64 pack/unpack [message #184608 is a reply to message #184595] |
Sun, 12 January 2014 21:09   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 1/12/2014 11:00 AM, Christoph Michael Becker wrote:
> Jerry Stuckle wrote:
>
>> 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.
>
> Jerry, please note that Ben, to whom you've replied, is not the OP. :)
>
Yes, I know. But he keeps referring to information that is > 15 years
old. PHP has changed a lot since then, but we just wants to argue.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]