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

From: Date: Tue, 22 Aug 2017 17:03:00 +0000
Subject: Doc #74417 [Asn]: 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-14912@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: cmb@php.net Reported by: vedad at kajtaz dot net Summary: long2ip() is documented to accept a string, but TypeError thrown with strings Status: Assigned Type: Documentation Problem Package: Documentation problem Operating System: FreeBSD 11.0 PHP Version: 7.1.3 -Assigned To: laruence +Assigned To: cmb Block user comment: N Private report: N New Comment: > 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'));" Previous Comments: ------------------------------------------------------------------------ [2017-08-15 09:48:06] indan at nul dot nu 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. ------------------------------------------------------------------------ [2017-08-12 02:39:02] laruence@php.net 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. ------------------------------------------------------------------------ [2017-08-12 02:10:30] ajf@php.net This can be worked around: $ sapi/cli/php -r "declare(strict_types=1); var_dump(long2ip((int)'2130706433'));" string(9) "127.0.0.1" ------------------------------------------------------------------------ [2017-08-12 01:57:01] laruence@php.net I don't have 32bit env , just one question what does ip2long behavior in this case? ie: var_dump(ip2long("192.168.0.1")); ------------------------------------------------------------------------ [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); } ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=74417 -- Edit this bug report at https://bugs.php.net/bug.php?id=74417&edit=1

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