Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68736
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.212.48 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAN=kQJeDjYNcy2yYDBa+Zc8LpbD4W1z69dj3RhtfT_D1J7rWfg@mail.gmail.com>
References: <CADqTB_iSQ51FQRSCtwV4kVK7ekOY5XZx8hTPWFc-AzzhDMDdyw@mail.gmail.com>
	<CADqTB_hj91-Qmex83H6WXrjtTbYKpmNZaNh-4e8YPQH6X7SJbQ@mail.gmail.com>
	<CAN=kQJeDjYNcy2yYDBa+Zc8LpbD4W1z69dj3RhtfT_D1J7rWfg@mail.gmail.com>
Date: Fri, 30 Aug 2013 13:06:46 -0400
Message-ID: <CADqTB_i-hMqeRSV=z2NiaYc79k4g9vXa=kciJw2gqyK3bOm4vg@mail.gmail.com>
To: Matthew Leverton <leverton@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b6d8cc865654d04e52d3f8f
Subject: Re: [PHP-DEV] Re: crc32() and ip2long() return values
From: rasmus@mindplay.dk (Rasmus Schultz)

--047d7b6d8cc865654d04e52d3f8f
Content-Type: text/plain; charset=ISO-8859-1

Perhaps this illustrates the problem better:

$value = sprintf('%u', ip2long('255.255.255.0'));
var_dump($value, (int) $value);

$a = array();
$a[$value] = 'foo';
var_dump($a);

Output on 64-bit:

string(10) "4294967040"
int(4294967040)
array(1) {
  [4294967040]=>
  string(3) "foo"
}

No problem.

But - output on 32-bit:

string(10) "4294967040"
int(2147483647)
array(1) {
  ["4294967040"]=>
  string(3) "foo"
}

In this example, $value and (int) $value lead to incompatible results -
that's if your database access layer will let you store a string in an
integer column in the first place. Which, even if it will, when you get the
integer value back from the database and cast it to an integer, you have
the same problem again. If you query against the database using integer
values you computed, you have problems. And so on...



On Fri, Aug 30, 2013 at 12:27 PM, Matthew Leverton <leverton@gmail.com>wrote:

> On Fri, Aug 30, 2013 at 10:29 AM, Rasmus Schultz <rasmus@mindplay.dk>
> wrote:
> > No replies probably means no one cares. oh well.
> >
> > For the record, the examples I posted are wrong - the correct way to
> > convert the long values consistently appears to be:
> >
> > list($v) = array_values(unpack('l', pack('l',
> ip2long('255.255.255.0'))));
> >
> I had spotted the error, but didn't want to reply because I don't
> really understand what you are getting at.
>
> The core issue is that PHP doesn't provide a 32-bit unsigned integer
> on a 32-bit platform ... and/or that the size of integer changes
> depending on the platform. But I doubt that is going to change any
> time soon. Crippling 64-bit systems due to old, legacy 32-bit
> platforms is shortsighted.
>
> What's wrong with the manual's approach?
>
> $checksum = sprintf("%u", crc32("The quick brown fox jumped over the
> lazy dog."));
>
> Are you going to do further mathematical operations on it? You can
> take that string and stuff it into an uint32 field into a db without
> an issue.
>
> At the end of the day, there's no getting around that PHP programmers
> need to be aware of the difference between 32-bit and 64-bit systems
> ... it affects far more than these two particular functions.
>
> But if these two functions are particularly bothersome, a better "fix"
> IMO is just:
>
> $crc = crc32("12341234", CRC32_UINT32_STRING);
>
> Where the second parameter is CRC32_INT (default & current behavior),
> CRC32_INT32 (always negative if high bit is set), CRC32_UINT32_STRING,
> CRC32_HEX_STRING
>
> Forgive the poor names.
>
> --
> Matthew Leverton
>

--047d7b6d8cc865654d04e52d3f8f--