php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #67601 ip2long(), or a successor needs to support IPv6
Submitted: 2014-07-10 01:52 UTC Modified: 2020-12-07 13:46 UTC
Votes:3
Avg. Score:4.0 ± 0.8
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: gem at rellim dot com Assigned: cmb (profile)
Status: Wont fix Package: *Network Functions
PHP Version: 5.5.14 OS: any
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: gem at rellim dot com
New email:
PHP Version: OS:

 

 [2014-07-10 01:52 UTC] gem at rellim dot com 
Description:
------------
Currently ip2long() on works on some IP addresses: IPv4 addresses, not IPv6 addresses.

I would like it, or an ip2long-ng(), to also support IPv6 addresses.

Test script:
---------------
<?php

print_r( ip2long( '2607:400:0:1f3::1:6'));


Expected result:
----------------
The results should be something like:
0x26070400000001f30000000000010006

Actual result:
--------------
FALSE, since it is invalid IPv4 address, but is a valid IP address

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-06-26 19:27 UTC] jc at unternet dot net 
new features require approved RFC as per https://github.com/php/php-src/

128 bits cannot fit into a long int anyway, assuming "long" is defined as 64 bits. see https://stackoverflow.com/a/37250452/493161 for an easy workaround: `gmp_import(inet_pton($ip));`

I vote to close.
 [2017-06-26 19:30 UTC] spam2 at rhsoft dot net 
besides of RFC and what not - "for an easy workaround: `gmp_import(inet_pton($ip));`" is crap - in 2017 PHP needs to support ipv6 without userland code needs to know about it at all - period
 [2017-06-26 19:41 UTC] gem at rellim dot com 
"in 2017 PHP needs to support ipv6 without userland code needs to know about it at all - period"

+1
 [2017-06-26 22:04 UTC] jc at unternet dot net 
"PHP needs to support ipv6 without userland code needs to know about it at all - period"

get back to me when PHP_INT_MAX returns 170141183460469231731687303715884105727
 [2017-06-26 22:07 UTC] spam2 at rhsoft dot net 
> get back to me when PHP_INT_MAX returns 170141183460469231731687303715884105727

that's ridiculous at it's own on modern hardware and a weak excuse
 [2020-12-07 13:46 UTC] cmb@php.net
-Status: Open +Status: Wont fix -Assigned To: +Assigned To: cmb
 [2020-12-07 13:46 UTC] cmb@php.net 
IPv6 uses 128bit addresses; these cannot be converted to int, like
jc already said, so this request makes no sense.  Also, like jc
already pointed out, there is inet_pton() which can be combined
with other existing functions to get a numeric string[1].

> in 2017 PHP needs to support ipv6 without userland

Well, it's 2020, so this claim is no longer relevant.

[1] <https://3v4l.org/tad1D>
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 19 00:01:29 2024 UTC