3 ms·

Oh no, that's another shorthand that's different from all the others. A single number should be interpreted as a big-endian uint32, and so "1" should be "0.0.0.

Oh no, that's another shorthand that's different from all the others. A single number should be interpreted as a big-endian uint32, and so "1" should be "0.0.0.1". However, I can confirm that `ip` interprets it as "1.0.0.0", even though you should have to write "1.0" for that. Ugh.

FreshFries 6y ago
macOS here: % ping 1 PING 1 (0.0.0.1): 56 data bytes % ping 1.0 PING 1.0 (1.0.0.0): 56 data bytes
j1elo 6y ago
Well I did think of that, it technically is not a Class-A because it should have 2 parts. My conclusion was that maybe what happens is that "1", while incorrect, is flexibly parsed as "1.0" and thus it would become "1.0.0.0". But you're right that, given the uint32 representation does exist, the most correct thing to do seems to interpret it as "0.0.0.1"... unless an exception to the rule exists somewhere, and 'ip' is actually doing it right!
- gravitas 6y ago
  I was curious as well, turns out they're using a non-standard parsing with a comment in the function explaining why: /* This uses a non-standard parsing (ie not inet_aton, or inet_pton) * because of legacy choice to parse 10.8 as 10.8.0.0 not 10.0.0.8 */ src: https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/lib/utils.c#n450 https://git.kernel.org/pub/scm/network/iproute2/iproute2.git... (the entry point to start tracing down to the above inner function is right around here: https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/ip/iproute.c#n2058 https://git.kernel.org/pub/scm/network/iproute2/iproute2.git... )
  - j1elo 6y ago
    Conclusion: explicit is better than implicit, and what's more, in this case the implicit alternative was depending on a non-standard choice made in the specific tool for obscure, legacy reasons.
    - gravitas 6y ago
      This fits almost any situation (explicit vs. implicit) and I'm a big fan - when mentoring I tend to say "yes that was the default when you looked today, how do you know it won't change tomorrow? If you want specific behaviour, be explicit don't trust defaults." (more or less, depends on subject - commandline switches to code loops, same advice)

FreshFries 6y ago

macOS here: % ping 1 PING 1 (0.0.0.1): 56 data bytes % ping 1.0 PING 1.0 (1.0.0.0): 56 data bytes

j1elo 6y ago

Well I did think of that, it technically is not a Class-A because it should have 2 parts. My conclusion was that maybe what happens is that "1", while incorrect, is flexibly parsed as "1.0" and thus it would become "1.0.0.0". But you're right that, given the uint32 representation does exist, the most correct thing to do seems to interpret it as "0.0.0.1"... unless an exception to the rule exists somewhere, and 'ip' is actually doing it right!

gravitas 6y ago
I was curious as well, turns out they're using a non-standard parsing with a comment in the function explaining why: /* This uses a non-standard parsing (ie not inet_aton, or inet_pton) * because of legacy choice to parse 10.8 as 10.8.0.0 not 10.0.0.8 */ src: https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/lib/utils.c#n450 https://git.kernel.org/pub/scm/network/iproute2/iproute2.git... (the entry point to start tracing down to the above inner function is right around here: https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/ip/iproute.c#n2058 https://git.kernel.org/pub/scm/network/iproute2/iproute2.git... )
- j1elo 6y ago
  Conclusion: explicit is better than implicit, and what's more, in this case the implicit alternative was depending on a non-standard choice made in the specific tool for obscure, legacy reasons.
  - gravitas 6y ago
    This fits almost any situation (explicit vs. implicit) and I'm a big fan - when mentoring I tend to say "yes that was the default when you looked today, how do you know it won't change tomorrow? If you want specific behaviour, be explicit don't trust defaults." (more or less, depends on subject - commandline switches to code loops, same advice)