-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
proposal: net: add MarshalText/UnmarshalText to HardwareAddr #29678
Comments
Considering there is a |
There are backwards compatibility concerns with adding MarshalText/UnmarshalText where they did not exist before. Was it possible to marshal these to JSON/Gob/XML before and then decode them back? If so, we can't break the old encoding. Or even if it was only possible to marshal, if that was a form other languages/tools knew, we can't change that either. While we're on the topic, do we need to think about net.IPMask too? |
Waiting for someone to dig into whether there are compatibility issues here. |
/cc @mikioh |
Timed out in state WaitingForInfo. Closing. (I am just a bot, though. Please speak up if this is a mistake or you have the requested information.) |
Just FYI. As far as I can see/remember;
|
Also net.IPNet? I don't think so. As shown in #30264, there is a need for flexible IP address printer but simple, single-form text marshaler and unmarshaler might not fit for the actual needs, not only for classical telco sectors but tech sectors. |
Still looking for comments on compatibility issues. |
@rsc I've dug through the git history of the go repo and I can't seem to find anything that would indicate any backwards compatibility issues. If there are specific things you'd like me to look for, I'm more than happy to, but at this point, I don't see any harm in adding this function. |
The HardwareAddr type has the ability to be transformed to and from a string. However, this capability is not exposed in a manner suitable for use with various forms of marshalling and unmarshaling of text (e.g. JSON or YAML). Let's add the proper functions so that HardwareAddr implements the TextMarshaller and TextUnmarshaler interfaces from the encoding package. Fixes golang#29678
The HardwareAddr type has the ability to be transformed to and from a string. However, this capability is not exposed in a manner suitable for use with various forms of marshalling and unmarshaling of text (e.g. JSON or YAML). Let's add the proper functions so that HardwareAddr implements the TextMarshaller and TextUnmarshaler interfaces from the encoding package. Fixes golang#29678
Change https://golang.org/cl/196817 mentions this issue: |
@klnusbaum The backward compatibility issue is that someone could have marshaled Is there some reason that that is impossible? |
@ianlancetaylor I'm a little confused here. If someone marshaled a hardware address on their own into JSON, why would Go be on the hook for being able to unmarshal that value with this newly introduced code? That seems somewhat unreasonable to me. |
In general, it seems reasonable that if you marshal a |
Ah, ok. So this I think is the source of my confusion. I'm unaware of any way to marshal or unmarshal a |
unless you're talking about a developer manually calling |
Since that is an unusual format for MAC addresses, I guess it wasn't widely used, so there shouldn't be many compatibility issues.
If that's an issue, the |
Ah, so in other words, we're saying that we must remain backwards compatible with the raw marshaling of bytes? i.e. the behavior of this (which will marshal using the default marshal behavior of
If that's the case, then yea, I think we can do as @zigazeljko suggested, fallback to raw byte unmarshaling in the case of ParseMAC failing. @ianlancetaylor do you think that would work? |
The main thing the PR is missing is consensus on this proposal that we want to do this. |
On hold for understanding the compatibility issues. I will try to do that at some point if no one else beats me to it. |
This issue is not updated as of August 10, 2022; any news? |
I took a stab a making a fix, but got hung up on maintaining backwards compatibility. Right now, if you write a MAC address out to, for example, yaml, its hex representation is output. So in order to not break things, we need to be able to:
|
Change https://go.dev/cl/641935 mentions this issue: |
I wrote https://go.dev/cl/641935 which implements the expected JSON marshaling, and supports both the new JSON marshaling and the old one. This addresses the compatibility concern, in that we can unmarshal a marshaled Taking off hold. |
@ianlancetaylor this is great. Looks like you went with implementing the |
@klnusbaum Yes. For simple cases like this I can't see any reason to use |
I believe based on the accepted proposal in #10275 (comment) , this wouldn't be allowed as it breaks marshaling on a new version and unmarshaling on an old version. |
@seankhliao Thanks, I forgot about that. We'll have to decide whether this seems like an important enough case to worry about marshaling with new programs and unmarshaling with old ones. We could, of course, add a |
Or it could be done for json/v2 only. |
Changing the output of serialization from using encoding/json to encoding/json/v2 would be a similar kind of break discussed in #10275, where if you care about compatibility between old and new versions of your code through serialized data, you can't do it. |
This proposal has been added to the active column of the proposals project |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What did you do?
I'm trying to unmarshal json content into
net.IP
andnet.HardwareAddr
.Both types are actually of type
[]byte
Since
net.IP
implementsjson.Marshaler
, it works as expected. However, net.HardwareAddr does not and fails with the error "illegal base64 data at input byte 2" (that's the position of the separator).Here's an example:
https://play.golang.org/p/HOBBAyvpfrK
I found the google group discussion about adding the Marshaller to the
net.IP
type: https://groups.google.com/forum/#!topic/golang-nuts/io8aHJarm6UWhat did you expect to see?
I expect
net.HardwareAddr
to be consistent withnet.IP
and implementjson.Marshaler
.Strings in the form of
"ab:cd:ef:ab:cd:ef"
inside json should be parsable to MAC addresses.The text was updated successfully, but these errors were encountered: