Valdis Klētnieks wrote on 26/09/2021 01:44:
19:17:38 0 [~] ping 2130706433 PING 2130706433 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.126 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.075 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.063 ms 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.082 ms ^C --- 2130706433 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time84ms rtt min/avg/max/mdev = 0.063/0.086/0.126/0.025 ms
Works on Fedora Rawhide based on RedHat, Debian 10, and Android 9.
this is a good example of "might work but don't depend on it". The fact that it works at all is a historical curiosity which happened because the text format for ipv4 addresses was never formally specified, so when some of the tcp/ip code was originally written for bsd, it accepted unusual formats in some places, including: integers, octal, hex, binary and assuming zeros when the address is incompletely specified, among other things. The octal representation was a real problem because rfc790 specified decimal dotted quad notation with leading zeros, leading to a whole bag of pain for parsers because there is no way of knowing what a leading zero means in practice, and for 3-digit numbers where each digit is <= 7, there is no a-priori way of determining whether it's octal representation or decimal. Nick