Richard Harnden <richard.nospam@gmail.com> writes:

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.

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).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 02/08/2023 15:49, Scott Lurndal wrote:

Richard Harnden <richard.nospam@gmail.com> writes:

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.

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).

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 2 Aug 2023 16:05:56 +0100
Richard Harnden <richard.nospam@gmail.com> wrote:

On 02/08/2023 15:49, Scott Lurndal wrote:

Richard Harnden <richard.nospam@gmail.com> writes:

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.

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).

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

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

Didn't know it could do that!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 02 Aug 2023 15:49:06 +0000, Muttley wrote:

On Wed, 2 Aug 2023 16:05:56 +0100
Richard Harnden <richard.nospam@gmail.com> wrote:

On 02/08/2023 15:49, Scott Lurndal wrote:

Richard Harnden <richard.nospam@gmail.com> writes:

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.

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).

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

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

Didn't know it could do that!

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"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, August 2, 2023 at 9:21:11 AM UTC-7, Lew Pitcher wrote:

On Wed, 02 Aug 2023 15:49:06 +0000, Muttley wrote:

On Wed, 2 Aug 2023 16:05:56 +0100
Richard Harnden <richard...@gmail.com> wrote:

On 02/08/2023 15:49, Scott Lurndal wrote:

Richard Harnden <richard...@gmail.com> writes:

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.

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).

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

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

Didn't know it could do that!

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

:-)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Harnden <richard.nospam@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
doug@themcintyres.us

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)