ping and hex/octal in ip-address

[Richard Harnden]

Hi,

Is this a bug ... ?

$ ping 0xa.0xb.0xc.0xd
PING 0xa.0xb.0xc.0xd (10.11.12.13) 56(84) bytes of data.
^C
--- 0xa.0xb.0xc.0xd ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7171ms

$ ping 6.7.010.0x9
PING 6.7.010.0x9 (6.7.8.9) 56(84) bytes of data.
^C
--- 6.7.010.0x9 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4108ms

... non decimal in the dot-quad is new to me, anyway.

[Scott Lurndal]

Why would you consider it a bug rather than a feature?

If the ping command uses 'strtoui/strtoul/strtoull' to parse
the argument, it can simply specify '0' as the desired base
and strtoul will detect and accept any supported base (at least
8, 10 and 16).

[Richard Harnden]

That seems to be exactly what it's doing, yes.

Not exactly a bug - just something I'd never noticed before.

[Mut...@dastardlyhq.com]

Didn't know it could do that!

[Lew Pitcher]

You don't even have to stick with dotted-quad format. Witness:

12:19 $ 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.025 ms

:-)

--
Lew Pitcher
"In Skills We Trust"

[Philip Guenther]

Right: the inet_aton(3) and inet_addr(3) routines for converting textual IPv4 addresses into the 'machine' format did that from the start and the behavior actually ended up being specified in the X/Open XNS and POSIX standards for them.

On the other hand, the newer inet_pton(3) routine which supports both IPv4 and IPv6 is specified to *not* support those formats so whether this wart works for a given program depends on how it was implemented. Indeed, some implementations of ping have switched over to use inet_pton(). <shrug>


Philip Guenther

[Doug McIntyre]

Richard Harnden <richard...@gmail.com> writes:
>Is this a bug ... ?

No

My favorite is to visit https://010.010.010.010/ in your web browser.

Works fine.




--
Doug McIntyre
do...@themcintyres.us