[dave_universetf]

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.

[j1elo]

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]

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

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

[j1elo]

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]

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]

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