-
Notifications
You must be signed in to change notification settings - Fork 111
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
MultiAddress.String representation question #230
Comments
This is correct. |
I think there are edge cases like base64 where you can add extra padding which is trimmed off if you do the round trip. |
Actually no, I was completely wrong, there are plenty of counter examples where we canonicalize old encodings:
Generally they have the same semantics, |
In general though m2 should always succeed correct? |
should is doing heavy work here. Some weird edge case invalid thing can slip through the cracks. |
Thanks for clarity, there are several edge cases here generally around different encoding types. It does seem a bit troubling that the str representation isn't valid. (e.g. I have several cases where we error on m2 creation or if we do succeed !m.Equal(m2)), but I don't see a valid use case where someone would want to do this in production. As long as this doesn't sound alarming I'm satisfied with my current understanding and I'll close this issue. |
Hey I improved fuzzing and @sukunrt fixed a bunch of edge cases in 77f3edf.
cases with Again I don't think it's critical to have complete consistency but it's still nice. |
Fixed by #232 |
I'm trying to understand some of the caveats of the different NewMultiaddr functions. Is the string representation of a multiaddress supposed to be compatible with the string constructor? e.g.
Should NewMultiaddr ever fail? My understanding is that m2 should always succeed and that
m.Equal(m2)
should always be true.The text was updated successfully, but these errors were encountered: