Doc #74417 [Opn]: long2ip() is documented to accept a string, but TypeError thrown with strings

From: Date: Sat, 12 Aug 2017 01:57:03 +0000
Subject: Doc #74417 [Opn]: long2ip() is documented to accept a string, but TypeError thrown with strings
References: 1  Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-14891@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=74417&edit=1 ID: 74417 Updated by: laruence@php.net Reported by: vedad at kajtaz dot net Summary: long2ip() is documented to accept a string, but TypeError thrown with strings Status: Open Type: Documentation Problem Package: Documentation problem Operating System: FreeBSD 11.0 PHP Version: 7.1.3 -Assigned To: +Assigned To: laruence Block user comment: N Private report: N New Comment: I don't have 32bit env , just one question what does ip2long behavior in this case? ie: var_dump(ip2long("192.168.0.1")); Previous Comments: ------------------------------------------------------------------------ [2017-04-24 08:43:47] indan at nul dot nu 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); } ------------------------------------------------------------------------ [2017-04-21 14:57:59] vedad at kajtaz dot net Note that the original bug report is based on a 64bit FreeBSD build. ------------------------------------------------------------------------ [2017-04-21 08:18:01] indan at nul dot nu 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' */ ------------------------------------------------------------------------ [2017-04-20 14:32:53] indan at nul dot nu 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. ------------------------------------------------------------------------ [2017-04-11 16:20:50] vedad at kajtaz dot net Description: ------------ The long2ip() signature in documentation is: string long2ip ( string $proper_address ) Yet, as of PHP 7.1 (unlike PHP 7.0) TypeError is thrown with strict_types=1 when a string is provided: PHP Fatal error: Uncaught TypeError: long2ip() expects parameter 1 to be integer, string given in ... Related bug reports: #65017 and #71100 Test script: --------------- declare(strict_types=1); long2ip('2130706433'); Actual result: -------------- PHP Fatal error: Uncaught TypeError: long2ip() expects parameter 1 to be integer, string given in ... ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=74417&edit=1

« previous php.doc.bugs (#14891) next »