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 Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
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

Pull Requests

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-2025 The PHP Group
All rights reserved. 		Last updated: Fri Jan 03 06:01:28 2025 UTC