下面这段python代码在macOS和linux时运行的结果是不同的
import socket
ip = socket.inet_pton(socket.AF_INET6, '1:2:3:0:5:6:7:8')
print socket.inet_ntop(socket.AF_INET6, ip)
macOS
1:2:3::5:6:7:8
linux
1:2:3:0:5:6:7:8
可以看到区别在于,中间的一个0有没有压缩
哪一个行为更合理呢?
Due to some methods of allocating certain styles of IPv6 addresses, it will be common for addresses to contain long strings of zero bits. In order to make writing addresses containing zero bits easier, a special syntax is available to compress the zeros. The use of "::" indicates one or more groups of 16 bits of zeros. The "::" can only appear once in an address. The "::" can also be used to compress leading or trailing zeros in an address.
按RFC上的说法,macOS的行为是合理的。
那么这个行为是怎么造成的呢? 是由于linux的glibc库和macOS的libc库实现差异造成的。
下面这段C代码也可以复现上述的问题
#include
int main() {
char buf[64];
inet_pton(AF_INET6, "1:2:3:0:5:6:7:8", buf);
char str[64];
inet_ntop(AF_INET6, buf, str, 64);
printf("%sn", str);
}
if (best.base != -1 && best.len < 2) //
best.base = -1;
glibc库inet_ntop处理IPv6地址的这个行为,不确定是不是bug
最后
以上就是悲凉芝麻最近收集整理的关于linux内核中使用inet_ntop,使用inet_ntop转换IPv6地址时在macOS和linux上的行为不一样...的全部内容,更多相关linux内核中使用inet_ntop,使用inet_ntop转换IPv6地址时在macOS和linux上内容请搜索靠谱客的其他文章。
发表评论 取消回复