-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ipv4Net
FromStr
allows host bits to be set in CIDR
#33
Comments
FromStr
allows host bits to be set in CIDRIpv4Net
FromStr
allows host bits to be set in CIDR
Just hit another downside of not rejecting bad subnets or at least auto running |
Thanks @nu11ptr. Yep it was designed that way. Rejecting it would be preferable to silently transforming it. Possibly that's what I should've done, but the structure can show up in all kinds of places that aren't purely IP routes/prefixes, so I wanted to leave it flexible. Wonder if it's worth surveying users to see what they prefer and if changing this behaviour in a future release would affect them? Could leave this to a v3 update |
Thanks for the reply and consideration. I look at this way - your crate is either the only one, or certainly the most popular, to provide this. Thus, anyone who wants to implement network/subnet-like functionality is either using your crate or reinventing. I would expect almost all those who need to do this are going to want the behavior I describe (and I agree rejecting is better). It would be easy to leave a backdoor API if someone really needs the old behavior ( |
…ex seemed to have errors, simplified it, though it will not perform strict validation anymore.
This should return an error since a /24 would require a zero 4th octet, but it accepts it. Worse, it doesn't seem to transform it, but keeps all the bits set.
NOTE: I just found the
trunc
function so now I'm starting to think this is per design. For the record, I think this is broken behavior as these are in no way valid subnets. My preference, and I believe correct behavior, would be to reject these outright. However, if this is kept, it would be nice iftrunc
could at least run by default so Serde, etc. can properly transform the data. Since there is no way to calltrunc
in the deserialization path that I'm aware of, it has to be a per call site type thing which is error prone.Thanks for looking at this.
The text was updated successfully, but these errors were encountered: