Repository navigation
Add IPAddr#to_hex - #126
Conversation
@datibbaw I think
|
Thanks @taketo1113. The |
taketo1113
left a comment
There was a problem hiding this comment.
So perhaps exposing
#_reversecould be a consideration? Or have ato_dottedwhich implements%{i}?
@datibbaw I agree that if we make IPAddr#_reverse a public method, it would be better to give it a different name.
However, I would not accept the name to_dotted at this point. There have been several proposals in the IETF in the past to represent IPv6 addresses using dotted notation, so I think we should choose the name carefully, considering that dotted notation might be used for a different purpose in the future.
I think adding IPAddr#to_hex and using it in hton and _reverse would be fine. So, how about adding only to_hex in this Pull Request, without implementing the RFC 7208 %{i} macro?
Returns the hexadecimal representation of the address value, right adjusted to the address size (8 characters for IPv4, 32 for IPv6).
Derp, thanks for spotting that. Removed! |
|
@datibbaw Merged. Thank you! |
|
As a follow-up, I benchmarked the changes and confirmed significant performance improvements for both Benchmark resultsBenchmark code |
Adds
IPAddr#to_hex, which returns the hexadecimal representation of the address value, right adjusted to the address size — 8 characters for IPv4, 32 for IPv6:Motivation: consumers that need the padded hex form of an address — most notably SPF macro expansions (RFC 7208
%{ir}), but also DNS reverse-name construction and protocol encodings — currently have to reimplement the family-dependent padding themselves:Having this in the library would help reduce the external branching in other projects.
I decided to make this raise an
AddressFamilyErrordespite it being impossible to create an instance of a family type outside of IPv4 or IPv6.