route: error on IPv4 network routes with incorrect destination

[• karels]

Summary

Route destinations like 10/8 are most likely intended as a shorthand
for 10.0.0.0/8, but instead it means 0.0.0.10/8, which includes
only bits in the host part of the mask, and hence adds a route to
0.0.0.0/8. In 12.x, there was code to "do what I mean", which was
removed as part of a cleanup of old network class remnants. Given
that we have gone this long without that code, do not restore that
behavior. Instead, detect the issue and produce an error.
Specifically, if there are no dots in a numeric IPv4 address, the
mask is specified with CIDR notation (using a slash), and there are
bits set in the host part, produce an error like this for 10/8:

route: malformed address, bits set after mask; 10 means 0.0.0.10

PR: 258874
MFC after: 1 week

[• karels]

Any comments on this, including the plan to MFC? I didn't reply to Ed's comment on the bug about possibly erroring on 15, and restoring the workaround on 13 and 14,. But I think it will have been long enough since this "worked" that people will have gotten used to the new behavior unless they stick with 12.4 until 13.3 is out.

[emaste]

it's a bit cumbersome for me to understand the expression, you could extract it to a static inline helper if you wanted
but I'm fine with the logic of making the error explicit

[• karels]

I tried formatting the check as a separate function, and that doesn't help much. The main part of the expression (computing the host part) still doesn't fit on one line. I think I'll leave it as it is.

[• karels]

Use local variables to factor out parts of long expression, simplify

[emaste]

sbin/route/route.c

1355

style(9) provides an explicit exemption to the 80-column guide line for strings like this:

Anything that is frequently grepped for, such as diagnostic, error, or
panic messages, should not be broken up over multiple lines despite this
rule.

I don't think it's particularly important here (because a grep expression including the format string %s is unlikely) but think it would be fine to unrwap this string if you are so inclined

[• karels]

sbin/route/route.c

1355

Thanks for the pointer. I would think that greps would look for "malformed address" or "bits set after mask", so I don't think I'll bother joining these.