crc32() and ip2long() return values

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

Hi,

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 recognise this from a comment on one of my SO answers here: http://stackoverflow.com/questions/13419921/how-should-a-crc32-be-stored-in-mysql/13420281#13420281

Instead of using list() and array_values() you can use current() on the return value to get the first array element from unpack()'s result.

echo current(unpack('l', pack('l', crc32(...))));
Admittedly only makes it marginally nicer to look at :)

I missed the fact that array_values() returns an array, and for some reason
the return-value from unpack() is base-1 with apparently no way to change
the key to a 0.

As an aside, the information I posted on the manual pages in the comments
is wrong, and the site currently offers no way to edit or remove a
comment... dangit...

Dear list,

I recently ran into big problems with crc32() and ip2long() both of which
I was using in the same codebase.

I know these issues have been debated at length in the past, but this
really needs to be fixed.

Anytime you persist these values (to any external medium, files or
databases) you're sitting on a time bomb.

I realize some of you have countless technical arguments why these
functions "work as they're supposed to", but php is a high-level language,
and these functions do not work consistently across platforms.

It can't be the developer's responsibility to write unit-tests for
return-values on internal functions - nor should we need to write elaborate
wrapper-functions for these functions to get them to work consistently.

There are dozens (if not nearing 100) different user-land solutions to
this problem, so it's not like the need isn't there - anyone who has ever
used these functions probably needed a work-around. The need for an
enormous red WARNING label, and elaborate explanation on the crc32()
documentation page says it all - nothing this simple, that has been
standardized for this long, should require an elaborate explanation,
complicated work-arounds or for that matter a lot of thought on the
developer's side.

Since a signed 32-bit integer value is the lowest common denominator,
that's what the functions ought to return, so that at least the return
value is consistent across platforms, and you can decide (for example)
whether to persist it to a signed or unsigned INT in a database, and except
it to work the same everywhere. (Databases at large, and at least MySQL,
correctly persists either signer or unsigned INT values across platforms.)

The simplest work-around I have been able to come up with so far, is this:

var_dump(unpack('l', pack('l', ip2long('255.255.255.0'))));

var_dump(unpack('l', pack('l', crc32('123456789_00_0'))));

Forcing the value into smaller (on some platforms) 32-bit integer, and
then unpacking it, provides a consistent value on 32-bit and 64-bit
systems, and on Windows.

Of course there is backwards compatibility to consider for this broken
behavior, so I propose the simplest solutions is to just add a new pair of
replacement functions. You don't need to deprecate the existing functions,
because they work as prescribed, however useless they may be for any
practical applications.

The new functions and backwards compatible implementations for older
versions of php might look like this:

/**

• @param string
• @return int a signed (32-bit) integer value
  */
  function ip2int($ip_string) {
  return unpack('l', pack('l', ip2long($ip_string)));
  }

/**

• @param int a signed integer value
• @return string
  */
  function int2ip($ip_int) {
  return long2ip($ip_int);
  }

/**

• @param string
• @return int a signed integer value
  */
  function crc32i($string) {
  return unpack('l', pack('l', crc32($string)));
  }

int2ip() would just be an alias for long2ip().

I spent almost a full day fighting with these functions and testing
work-arounds, and I bet every php developer who encounters a need for one
of these functions will some day sooner or later go through the same.

Userland solutions are not solutions to fundamental problems that affect
everyone who uses the functions.

Arguing that this behavior is "correct" by some technical definition, is
futile - the behavior is problematic for practical reasons, so technical
circumstances don't really matter here. Core functions need to actually
work consistently and predictably for as many users as possible -
optimizing for C developers and people with deep technical knowledge of
operating system and compiler specifics does not make sense for a language
like php.

Please look for reasons to agree rather than disagree out of spite.

As said, I know this has been debated at length in the past, and always
with the same outcome - but the simple fact is that these functions don't
work for the end-users, and they do not provide proper cross-platform
support.

No one cares how integers work internally, in C, in the CPU, or in the VM,
and it's not relevant.

There is no need to put anyone through all this unnecessary hardship.

These functions need to work for php developers.

• Rasmus Schultz