parsing "127"
Closed this issue · 3 comments
If you type netstat -rn on MacOS, the output will include a line like
Destination Gateway Flags Netif Expire
127 127.0.0.1 UCS lo0
I believe that "127" represents the CIDR "127.0.0.0/8", but rust-cidr parses this as "127.0.0.0/32". I'm not sure if this is a bug in rust-cidr's parsing or if it is just MacOS trying to be too helpful.
It's certainly odd. As an address, MacOS ping & libc parses "127" as "0.0.0.127" and "169.254" as "169.0.0.254". Yet as input to the "route" command, "127" is parsed as "127.0.0.0/8" and "169.254" as "169.254.0.0/16".
On Linux "ip route add" treats "127" as "127.0.0.0/32". "route add -net" throws SIOCADDRT when given "127" as input.
IMO, "route add -net" is the correct behaviour, but the fact that "ip route add" parses these example networks the same way as rust-cidr means that we can't call rust-cidr's behaviour wrong. So if you feel that parsing MacOS CIDR's is outside the scope of rust-cidr, feel free to close this issue.
I probably shouldn't have supported #1 in the first place... (at least not without an explicit network length).
(Background: parsing cidr/inet is currently implemented as "parse address" + "parse optional /... suffix, otherwise host address".)
- Changing this would be a semantic API break, undetectable at compile time. There needs to be a really good reason to do that.
- I really don't like classful logic or deriving the network length from how many octects were omitted.
I think you'll just have to write a parser for your specific application, or find the right tool/options to print them in a proper format (or, in this case, use some proper kernel interface directly). In other words: yes, this format is out of scope.
Various parser methods (e.g. parse_short_ip_cidr) are now exposed in the parsers module with 0.2.3