I've been playing around with the megacheck tool, and found that NullTestStrings type in encoding/json's tests is unused. It seems to be aimed at checking decoding of nulls into ",string" fields, but there were no tests, which is the first issue. The second is that if you create one, it fails: https://play.golang.org/p/5XjdhoDDkq.
--- FAIL: TestUnmarshalStringNulls (0.00s)
main.go:126: Unmarshal of null values failed: MustNotUnmarshalJSON was used
main.go:138: Unmarshal of null did not clear nulls.Map
main.go:141: Unmarshal of null did not clear nulls.Slice
main.go:144: Unmarshal of null did not clear nulls.Interface
main.go:147: Unmarshal of null did not clear nulls.PRaw
main.go:150: Unmarshal of null did not clear nulls.PTime
main.go:153: Unmarshal of null did not clear nulls.PBigInt
main.go:156: Unmarshal of null did not clear nulls.PText
main.go:159: Unmarshal of null did not clear nulls.PBuffer
main.go:162: Unmarshal of null did not clear nulls.PStruct
main.go:166: Unmarshal of RawMessage null did not record null: 123
It seems to me that there are some inconsistencies between decoding null into a simple field and decoding "null" into a ",string" field.
$ go version
go version devel +ca360c3 Sat Oct 7 22:12:36 2017 +0000 linux/amd64
$ go env
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build220310604=/tmp/go-build -gno-record-gcc-switches"
The text was updated successfully, but these errors were encountered:
I can mail a CL that adds the test or removes the struct, but I think that the fact that null with a simple field and "null" with a ",string" field behave differently is rather concerning. I think the behaviour should be the same. This will bite someone sooner or later. If you are afraid that it will break someone's code, I think this is covered by the promise:
Bugs. If a compiler or library has a bug that violates the specification, a program that depends on the buggy behavior may break if the bug is fixed. We reserve the right to fix such bugs.