Closed ian-hamlin closed 4 years ago
It is not exactly wrong. More precisely, it should be blamed on bad documentation or the API.
The u32
value returned by the first
or last
methods is used to represent an IPv4 byte array in native byte order (NE). However, u32::from(cidr.first_as_ipv4_addr())
always uses big-endian byte order (BE) to convert the byte array into an u32
value.
It is confusable because IP values are usually stored in big-endian (which is also known as network byte order). I plan to make this crate use BE instead of NE in the next minor version.
Thank you for the explanation, that makes perfect sense!
It's done.
Amazing, thanks.
Given the following example:
It prints the following:
The value for cidr last seems wrong, it should be 1686110207
Edit* The value for first also seems wrong, I've updated the example to show the u32 conversions.