Peter Johnston

> @peterthejohnston, now would be a great time to offer any concerns you have before this get's merged. Thanks for the heads up, will take a look at this sometime...

Apologies for my very delayed reply. > See also discussion in https://github.com/bluejekyll/trust-dns/issues/158. Thanks for the pointer! > @peterthejohnston in your ideal end state, would sorting ever be off? ... Because...

Oops, I wrote [a test](https://github.com/peterthejohnston/ipnet/commit/a374b5adfe84fd4707584f2de32e72a215e3d4a8) and it looks like the ipnet parser already doesn't allow octal or hex format.

Yeah, that's interesting. I have a theory: - in the ipnet copy, when reading an octet in an IPv4 address, `max_digits` is [specified as 3](https://github.com/krisprice/ipnet/blob/master/src/parser.rs#L166), which would have correctly triggered...

But `parking_lot` [depends](https://github.com/Amanieu/parking_lot/blob/master/Cargo.toml#L14) specifically on `parking_lot_core = "0.9.0"`, so a new minor release of core wouldn't result in its being pulled into `parking_lot`. So I think if I want `parking_lot`...

I know that it's semver compatible, but I guess what I'm getting at is that if I were to `cargo vendor` `parking_lot`, I'm pretty sure it would pull in `parking_lot_core`...

Gotcha, I didn't realize that specifying a full version worked that way. Thanks for clarifying.

This should do it: #334 Although a maintainer would need to publish the new release to crates.io.

I think I'm running into the same issue as this. See this [playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=e1b7d705ae6d130c78c94e370cf3571b) for a demonstration. It looks like supertrait bounds are getting formatted to fit under a certain maximum...