Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #12593 > unrolled thread

signed int64 pack/unpack

Back to article view | Back to comp.lang.php

Contents

  signed int64 pack/unpack cameron7@gmail.com - 2014-01-11 18:18 -0800
    Re: signed int64 pack/unpack Jerry Stuckle <jstucklex@attglobal.net> - 2014-01-11 21:35 -0500
      Re: signed int64 pack/unpack cameron7@gmail.com - 2014-01-11 18:46 -0800
        Re: signed int64 pack/unpack The Natural Philosopher <tnp@invalid.invalid> - 2014-01-12 02:59 +0000
          Re: signed int64 pack/unpack Jerry Stuckle <jstucklex@attglobal.net> - 2014-01-11 22:03 -0500
          Re: signed int64 pack/unpack cameron7@gmail.com - 2014-01-11 19:10 -0800
        Re: signed int64 pack/unpack Jerry Stuckle <jstucklex@attglobal.net> - 2014-01-11 22:04 -0500
    Re: signed int64 pack/unpack Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-01-12 02:42 +0000
      Re: signed int64 pack/unpack Jerry Stuckle <jstucklex@attglobal.net> - 2014-01-11 22:01 -0500
        Re: signed int64 pack/unpack cameron7@gmail.com - 2014-01-11 19:08 -0800
        Re: signed int64 pack/unpack Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-01-12 03:11 +0000
          Re: signed int64 pack/unpack Jerry Stuckle <jstucklex@attglobal.net> - 2014-01-11 22:15 -0500
            Re: signed int64 pack/unpack Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-01-12 12:37 +0000
              Re: signed int64 pack/unpack Jerry Stuckle <jstucklex@attglobal.net> - 2014-01-12 10:51 -0500
                Re: signed int64 pack/unpack Christoph Michael Becker <cmbecker69@arcor.de> - 2014-01-12 17:00 +0100
                  Re: signed int64 pack/unpack Jerry Stuckle <jstucklex@attglobal.net> - 2014-01-12 16:09 -0500
                    Re: signed int64 pack/unpack Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-01-12 22:35 +0000
                      Re: signed int64 pack/unpack Jerry Stuckle <jstucklex@attglobal.net> - 2014-01-12 17:59 -0500
                        Re: signed int64 pack/unpack Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-01-13 01:59 +0000
                Re: signed int64 pack/unpack Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-01-12 22:30 +0000
      Re: signed int64 pack/unpack cameron7@gmail.com - 2014-01-11 21:54 -0800
        Re: signed int64 pack/unpack cameron7@gmail.com - 2014-01-12 07:25 -0800
          Re: signed int64 pack/unpack Jerry Stuckle <jstucklex@attglobal.net> - 2014-01-12 11:11 -0500
          Re: signed int64 pack/unpack Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-01-12 23:27 +0000
            Re: signed int64 pack/unpack cameron7@gmail.com - 2014-01-12 16:03 -0800
            Re: signed int64 pack/unpack cameron7@gmail.com - 2014-01-12 16:22 -0800
              Re: signed int64 pack/unpack Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-01-13 01:20 +0000
    Re: signed int64 pack/unpack Christoph Michael Becker <cmbecker69@arcor.de> - 2014-01-12 17:37 +0100

Page 1 of 2  [1] 2  Next page →

#12593 — signed int64 pack/unpack

Hi,

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.  And of course even though double comes back with 8 length it's a floating point and thus loses precision.

Any thoughts?  Any help would be greatly appreciated.

BTW, unsigned int64 seems relatively straightforward, but signed int64 has been unusually difficult to figure out.

Thanks

[toc] | [next] | [standalone]

#12594

On 1/11/2014 9:18 PM, cameron7@gmail.com wrote:
> Hi,
>
> 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.  And of course even though double comes back with 8 length it's a floating point and thus loses precision.
>
> Any thoughts?  Any help would be greatly appreciated.
>
> BTW, unsigned int64 seems relatively straightforward, but signed int64 has been unusually difficult to figure out.
>
> Thanks
>

You're on a 64 bit machine, but are you using a 64 bit OS and 64 bit PHP?

As for thoughts - how about some detail?  What's you code?  What do you 
expect?  What do you get?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#12596

Hi, yes, sorry I am running 64-bit OS and 64-bit PHP.  PHP_INT_MAX is giving appropriate value.

Specifics from `php -i`:  PHP Version => 5.4.6-1ubuntu1.5

The code has become extremely ugly, and still not working perfectly, thus the reason for trying to find others who may have experience with this.  The pack / unpack functions don't provide support for 64-bit integers directly so I'm looking for at least a sound "hack".

I've tried all sorts of things, from base_convert to simply trying to extract and iterate over a bitwise comparison against each bit in 4 separate 16-bit ints, but nothing I've tried so far is working correctly.

Basically, the context for this is I'm writing a client for a custom protocol in which several of the components of that protocol in requests and responses require big endian 64-bit signed int, thus the reason for the need to pack / unpack.

[toc] | [prev] | [next] | [standalone]

#12597

On 12/01/14 02:46, cameron7@gmail.com wrote:
> Hi, yes, sorry I am running 64-bit OS and 64-bit PHP.  PHP_INT_MAX is
> giving appropriate value.
>
> Specifics from `php -i`:  PHP Version => 5.4.6-1ubuntu1.5
>
> The code has become extremely ugly, and still not working perfectly,
> thus the reason for trying to find others who may have experience
> with this.  The pack / unpack functions don't provide support for
> 64-bit integers directly so I'm looking for at least a sound "hack".
>
> I've tried all sorts of things, from base_convert to simply trying to
> extract and iterate over a bitwise comparison against each bit in 4
> separate 16-bit ints, but nothing I've tried so far is working
> correctly.
>
> Basically, the context for this is I'm writing a client for a custom
> protocol in which several of the components of that protocol in
> requests and responses require big endian 64-bit signed int, thus the
> reason for the need to pack / unpack.
>

I have to say this is where I would probably be trying to write a C 
library and wrap it in PHP..

Or write a C daemon and interrogate that..via a named pipe or system 
type call.

This is system level programming and PHP is simply not the right tool 
for it.





-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#12600

On 1/11/2014 9:59 PM, The Natural Philosopher wrote:
> On 12/01/14 02:46, cameron7@gmail.com wrote:
>> Hi, yes, sorry I am running 64-bit OS and 64-bit PHP.  PHP_INT_MAX is
>> giving appropriate value.
>>
>> Specifics from `php -i`:  PHP Version => 5.4.6-1ubuntu1.5
>>
>> The code has become extremely ugly, and still not working perfectly,
>> thus the reason for trying to find others who may have experience
>> with this.  The pack / unpack functions don't provide support for
>> 64-bit integers directly so I'm looking for at least a sound "hack".
>>
>> I've tried all sorts of things, from base_convert to simply trying to
>> extract and iterate over a bitwise comparison against each bit in 4
>> separate 16-bit ints, but nothing I've tried so far is working
>> correctly.
>>
>> Basically, the context for this is I'm writing a client for a custom
>> protocol in which several of the components of that protocol in
>> requests and responses require big endian 64-bit signed int, thus the
>> reason for the need to pack / unpack.
>>
>
> I have to say this is where I would probably be trying to write a C
> library and wrap it in PHP..
>
> Or write a C daemon and interrogate that..via a named pipe or system
> type call.
>
> This is system level programming and PHP is simply not the right tool
> for it.
>
>
>
>
>

You'd write a 5,000 line C program to say "Hello, World".

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#12603

I definitely have mixed view on this.  While I agree PHP isn't system-level programming language, I'm seeing more and more binary protocols for web infrastructure, which leads me to believe PHP should have better binary support.

[toc] | [prev] | [next] | [standalone]

#12601

On 1/11/2014 9:46 PM, cameron7@gmail.com wrote:
> Hi, yes, sorry I am running 64-bit OS and 64-bit PHP.  PHP_INT_MAX is giving appropriate value.
>
> Specifics from `php -i`:  PHP Version => 5.4.6-1ubuntu1.5
>
> The code has become extremely ugly, and still not working perfectly, thus the reason for trying to find others who may have experience with this.  The pack / unpack functions don't provide support for 64-bit integers directly so I'm looking for at least a sound "hack".
>
> I've tried all sorts of things, from base_convert to simply trying to extract and iterate over a bitwise comparison against each bit in 4 separate 16-bit ints, but nothing I've tried so far is working correctly.
>
> Basically, the context for this is I'm writing a client for a custom protocol in which several of the components of that protocol in requests and responses require big endian 64-bit signed int, thus the reason for the need to pack / unpack.
>

That may be, but without knowing exactly what you're doing and what you 
expect, any attempt to help you would be a waste of both your and our time.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#12595

cameron7@gmail.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.

>  And of course even though double comes back with 8
> length it's a floating point and thus loses precision.
>
> Any thoughts?  Any help would be greatly appreciated.

You could, perhaps, just pack the two halves.  Of course doing it
yourself rather defeats the purpose, but I am not sure there is another
way.

Depending on what you need this for, you could consider another format
altogether (ASCII, for example).

> BTW, unsigned int64 seems relatively straightforward, but signed int64
> has been unusually difficult to figure out.

How are you doing unsigned 64-bit ints?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#12599

On 1/11/2014 9:42 PM, Ben Bacarisse wrote:
> cameron7@gmail.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.

What do you get when you do:

<?php
echo PHP_INT_MAX . "\n";
?>


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#12602

9223372036854775807

I'm working up a more digestible summary should be back later this evening.

[toc] | [prev] | [next] | [standalone]

#12604

Jerry Stuckle <jstucklex@attglobal.net> writes:

> On 1/11/2014 9:42 PM, Ben Bacarisse wrote:
>> cameron7@gmail.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.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#12605

On 1/11/2014 10:11 PM, Ben Bacarisse wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
>
>> On 1/11/2014 9:42 PM, Ben Bacarisse wrote:
>>> cameron7@gmail.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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#12607

Jerry Stuckle <jstucklex@attglobal.net> writes:

> On 1/11/2014 10:11 PM, Ben Bacarisse wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>
>>> On 1/11/2014 9:42 PM, Ben Bacarisse wrote:
>>>> cameron7@gmail.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?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#12609

On 1/12/2014 7:37 AM, Ben Bacarisse wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
>
>> On 1/11/2014 10:11 PM, Ben Bacarisse wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>
>>>> On 1/11/2014 9:42 PM, Ben Bacarisse wrote:
>>>>> cameron7@gmail.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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#12610

Jerry Stuckle wrote:

> On 1/12/2014 7:37 AM, Ben Bacarisse wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>
>>> On 1/11/2014 10:11 PM, Ben Bacarisse wrote:
>>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>>
>>>>> On 1/11/2014 9:42 PM, Ben Bacarisse wrote:
>>>>>> cameron7@gmail.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. :)

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#12623

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@attglobal.net> writes:
>>>
>>>> On 1/11/2014 10:11 PM, Ben Bacarisse wrote:
>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>>>
>>>>>> On 1/11/2014 9:42 PM, Ben Bacarisse wrote:
>>>>>>> cameron7@gmail.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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#12625

Jerry Stuckle <jstucklex@attglobal.net> writes:
<snip>
> 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.

Old information can be accurate.  I don't know if it is in this case,
but it explains the OP's results better than the more recent PHP
documentation does.  When I asked you your opinion of what's happening,
you went all angry and weird.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#12627

On 1/12/2014 5:35 PM, Ben Bacarisse wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
> <snip>
>> 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.
>
> Old information can be accurate.  I don't know if it is in this case,
> but it explains the OP's results better than the more recent PHP
> documentation does.  When I asked you your opinion of what's happening,
> you went all angry and weird.
>

Exactly.  You don't know if the information is accurate.  Yet you 
continue to argue about it.

And more recent PHP documentation is more accurate because it relates to 
the CURRENT code base, not one that is over 15 years old.

As for getting "angry and weird" - maybe I'm just tired of arguing with 
people who base their position on old and/or inaccurate information (or 
translation thereof), and refuse to look at any other possibility.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#12636

Jerry Stuckle <jstucklex@attglobal.net> writes:

> On 1/12/2014 5:35 PM, Ben Bacarisse wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>> <snip>
>>> 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.
>>
>> Old information can be accurate.  I don't know if it is in this case,
>> but it explains the OP's results better than the more recent PHP
>> documentation does.  When I asked you your opinion of what's happening,
>> you went all angry and weird.
>>
>
> Exactly.  You don't know if the information is accurate.  Yet you
> continue to argue about it.
>
> And more recent PHP documentation is more accurate because it relates
> to the CURRENT code base, not one that is over 15 years old.

I could not find an explanation in the PHP documentation.  I am sure it
is more up-to-date (and more applicable) but there was no answer there
that I could see.

As it happens, the current code base references Perl for the behaviour.
A comment at the start of pack.c says:

/* pack() idea stolen from Perl (implemented formats behave the same as there)
 * Implemented formats are Z, A, a, h, H, c, C, s, S, i, I, l, L, n, N, f, d, x, X, @.
 */

So the code authors would have pointed me to Perl's pack function had I
not already gone there and, as documented, the code for the i and I are
based on the size of a C int (on the build system):

     case 'i': 
     case 'I': 
             while (arg-- > 0) {
                     php_pack(argv[currentarg++], sizeof(int), int_map, &output[outputpos]);
                     outputpos += sizeof(int);
             }
             break;

> As for getting "angry and weird" - maybe I'm just tired of arguing
> with people who base their position on old and/or inaccurate
> information (or translation thereof), and refuse to look at any other
> possibility.

I am open to other possibilities.  What is your opinion about what i and
I do and the size of integer they work with?.  I didn't pretend to know
what is actually going on, just what seemed to be going on.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#12624

Jerry Stuckle <jstucklex@attglobal.net> writes:
<snip>
> You can argue, or you can answer our questions and get help.

What questions didn't I answer?  Who is included in "our"?

As best I can tell you asked me one (which I answered) and I don't think
anyone else as has asked me any.

> 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.

Have I done something to make you angry?  We were having what I though
was civil exchange about a technical matter, and then this.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.php

csiph-web