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
