Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68753
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADqTB_hdUjjRd1G_kdMFsd6as4PFR=o9cYXi_fAHaZs1GGii+w@mail.gmail.com>
References: <CADqTB_iSQ51FQRSCtwV4kVK7ekOY5XZx8hTPWFc-AzzhDMDdyw@mail.gmail.com>
	<CADqTB_hj91-Qmex83H6WXrjtTbYKpmNZaNh-4e8YPQH6X7SJbQ@mail.gmail.com>
	<CAN=kQJeDjYNcy2yYDBa+Zc8LpbD4W1z69dj3RhtfT_D1J7rWfg@mail.gmail.com>
	<CADqTB_hdUjjRd1G_kdMFsd6as4PFR=o9cYXi_fAHaZs1GGii+w@mail.gmail.com>
Date: Fri, 30 Aug 2013 13:44:13 -0500
Message-ID: <CAN=kQJd5hViZ=SDh=BWG__FVJ9kmQQaq3OZv1xH=06+5LBBHVw@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Re: crc32() and ip2long() return values
From: leverton@gmail.com (Matthew Leverton)

On Fri, Aug 30, 2013 at 11:48 AM, Rasmus Schultz <rasmus@mindplay.dk> wrote:
> array(2) {
>   [2130706433]=>
>   string(3) "foo"
>   ["4294967040"]=>
>   string(3) "bar"
> }
>
> The keys are now two different types (string vs int) on 32-bit platforms,
> which leads to problems with strict comparison.
>
Prefix your keys with any alpha char to enforce a consistent string type.

> Another issue is persistence - if you save these to unsigned integer columns
> in database, and your data access layer converts them back to integers on
> load, the values are going to change again depending on what platform you're
> on.
>
I've never had that issue with any database layer I've ever worked
with. Not saying that no such db layer exists, but if you use PHP with
big integers, then you should treat them as strings in and out. If you
want to do math on them, then you have to use one of the bigint
libraries. If you want them for display purposes, keep them as
strings.

> To quote the specific case where I encountered this, I have an audit trail
> system that logs a lot of user activity - as an optimization, I hash and
> store certain keys using crc32() numeric values, since storing a 32-bit
> number is much cheaper (in terms of storage) than storing strings, as well
> as giving much faster queries.
>
Again, you should be able to store them from a string int to database
int without any issues. If so, I'd suggest fixing this at the database
access layer.

> Why would you consider a consistent function "crippled"?
>
It's crippled in the sense that it punishes people who are using
modern hardware from intelligently processing the return value. I have
a 64-bit system, and it returns a negative number for a 32-bit CRC?

> Look at the sheer number of comments on the crc32 manual page and tell me if
> you still think this works well for anybody... many of the comments
> (including mine!) aren't even correct and don't lead to predictable
> results...
>
A lot of PHP functions have tons of user error from people who haven't
bothered to read the existing manual entry or other comments.

> This should be easy but it is extremely hard.
>
There should never be the expectation that things "just work" without
having to understand the core features and limitations of the
language. To me, the examples you are giving are just two cases of the
larger problem of 32 vs 64 bit. There really is no getting around the
fact that scripts with integers behave differently depending on the
system.

So while I don't mean to sound dismissive of your complaints (because
they are valid), I just don't see how two bandaids over specific
instances of a larger problem do much good. Although, to be pragmatic,
I offered what I feel is a better solution than your extra functions.

--
Matthew Leverton