Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
encoding/gob: Go 1.2 cannot decode Go 1.1 gobs containing net.IP #6760
In Go 1.2, encoding/gob respects the new encoding.TextMarshaler and encoding.TextUnmarshaler methods, and net.IP adds those methods. Unfortunately, this means that the gob encoding of a net.IP changes from Go 1.1 to Go 1.2. That by itself might be okay: I don't believe people expect that Go 1.1 will be able to read Go 1.2 gobs. However, gob is also a bit picky about the decoding: if the type has a TextUnmarshaler, gob expects to get the TextMarshaler version of the encoding and does not accept an encoding of the underlying data. A Go 1.1 gob encoding of a net.IP will send the gob encoding of a standard byte. Go 1.2 gob will refuse to decode that form. The only other type we have added a MarshalText or MarshalBinary method to is time.Time. But time.Time already had a GobEncode and GobDecode methods, so its behavior with gob does not change. It appears that net.IP is the only affected type in the standard library. Possibilities: 1. Do nothing; allow Go 1.1 and Go 1.2 to be mutually unintelligible in gob when there is a net.IP involved. 2. Change gob to accept the concrete data representation during decode, so that Go 1.1 can talk to Go 1.2 but not vice versa. 3. Change gob to ignore MarshalText/UnmarshalText, allowing only MarshalBinary/UnmarshalBinary. 4. Remove net.IP's MarshalText/UnmarshalText methods, breaking encoding/json's support for net.IP (new in Go 1.2). 5. Replace net.IP's MarshalText/UnmarshalText methods with MarshalJSON/UnmarshalJSON, so that we keep encoding/json working well for Go 1.2. (Of course, the new generic methods were designed explicitly to avoid making package net mention JSON, so it is a bit of a shame not to use them.) I am leaning toward 5, which seems like the most limited change. Rob, what do you think?