Same problem with a 32-bit version of PHP 7.1.4 on Windows.
The 64-bit version of PHP 7.1.4 on Linux does not have this problem, so maybe it is only a bug in the 32-bit version of PHP.

Probably introduced by commit:

http://git.php.net/?p=php-src.git;a=commit;h=9b148d31d3e19ce8c726ebbab3ba6a9a24979a2f

As far as I know, I don't have strict types enabled.

The problem is that IP addresses in the high range (e.g. "192.168.0.1") result in a positive number which does not fit in an INT32_MAX. I don't see how this can be solved without added unsigned support to PHP, so I think the commit changing the argument from a string to an integer should be reverted.

Test code:

<?php
declare(strict_types=0);
error_reporting(E_ALL);

$n = (int)"3232242954"; // Will be truncated to INT32_MAX

echo "192.168.29.10 = " . gettype($n) . " = $n\n";
echo "Test 1: '" . long2ip($n) . "'\n";
echo "Test 2: '" . long2ip("3232242954") . "'\n";
echo "Test 3: '" . long2ip("173632452") . "'\n";

/*

Result:

192.168.29.10 = integer = 2147483647
Test 1: '127.255.255.255'
PHP Warning:  long2ip() expects parameter 1 to be integer, string given in t.php on line 7

Warning: long2ip() expects parameter 1 to be integer, string given in t.php on line 7
Test 2: ''
Test 3: '10.89.107.196'

*/

Note that the original bug report is based on a 64bit FreeBSD build.

They changed the signature of long2ip(), but didn't update the documentation. This applies to all platforms.

The original bug report proposes to fix the documentation to match the implementation.

I propose to revert the change and keep the documentation as it is, because the change breaks old code on 32-bit PHP. However confusing the function name is, it always has been like this.

If the change is not reverted, please also update the migration guide and add this backward incompatible change to the list. Work around for 32-bit PHP code:

function string2ip($s)
{
	if ($s > PHP_INT_MAX)
		$s = 2 * PHP_INT_MIN + $s;
	return long2ip($s);
}

I don't have 32bit env , just one question

what does ip2long behavior in this case?

ie: var_dump(ip2long("192.168.0.1"));

This can be worked around:

$ sapi/cli/php -r "declare(strict_types=1); var_dump(long2ip((int)'2130706433'));"
string(9) "127.0.0.1"

I got one 32bit box, and :

var_dump(ip2long("192.168.29.10"));

output:

int(-1062724342)

and :

var_dump(long2ip((-1062724342)));

output the correct value..

so in my opinion I don't think we should revert the fix here.

To answer ajf:

You have to use signed numbers greater than 2^31:

php -r "declare(strict_types=1); var_dump(long2ip((int)'3232242954'));"
string(15) "127.255.255.255"

Instead of "192.168.29.10". So no, it can't be worked around.

To laruence:

If you don't revert the prototype change from string to int, 32-bit PHP's long2ip() will choke on signed 32-bit IP addresses in the high range. This means long2ip() is not compatible between 64 and 32 bit PHP. It's your choice and I'm fine with whatever you decide. However, at least update all PHP documentation, including the migration guide. This is a backward incompatible change breaking existing code which currently works fine with PHP 7.0 or earlier.

Anything that puts IP addresses into a database as unsigned numbers will hit this problem on 32 bit. But only one left using 32 bit are Windows virtual machines, so I understand if PHP doesn't care about 32 bit anymore.

> So no, it can't be worked around.

Well, actually it can (albeit in a hackish way):

  php -r "declare(strict_types=1); var_dump(long2ip((int)(float)'3232242954'));"

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.