encoding/json: Encode results in invalid json if json.Number is not a valid number

[erikdubbelboer]

When encoding a struct with a json.Number containing an invalid number the resulting json is invalid.
See: http://play.golang.org/p/Xx4GjIgL_X

This is because of the exception made at: https://github.com/golang/go/blob/master/src/encoding/json/encode.go#L533

If this is intentional I think it should be documented in the json.Number documentation. If not it should be fixed by trying the number.Float64() method first and if it fails writing the result as a String enclosed in quotes.

[rsc]

Interesting. Too late for Go 1.5 but worth looking into early in Go 1.6.

Probably there needs to be a separate routine to validate the form of
JSON number syntax. It's not exactly what strconv.ParseFloat requires,
so using Float64 is only an approximation.

Also, probably both Marshal and Unmarshal should use it.
Unmarshaling "invalid" into a json.Number should not store 'invalid'.
It should be an error.

I think.

[erikdubbelboer]

I wrote a simple Valid() method for the Number type: http://play.golang.org/p/USf7fIxih7

This method could be used at decode.go#L783 to validate the number before setting it. I guess it's best to return an error when it's not valid.

The same goes for encode.go#L532.

If you want I can submit a diff for this using the Contribution Guidelines?

The function is based on this official JSON diagram:

It is quite a lot faster than using a regexp based method:

BenchmarkNumberValid        50000000            37.5 ns/op
BenchmarkNumberValidRegexp   2000000           846 ns/op

[josharian]

Yes, please mail your change, thanks. Note that the tree is frozen for Go 1.5, so a reviewer will mostly likely mark the change as being for Go 1.6, and it won't be reviewed until the tree reopens.

[erikdubbelboer]

Done: https://go-review.googlesource.com/#/c/12250/

[gopherbot]

CL https://golang.org/cl/12250 mentions this issue.

[erikdubbelboer]

While fuzzy testing I found some edge cases and fixed them.

I also added a regexp benchmark function to show the speed increase from not using the regexp:

BenchmarkNumberIsValid-8        50000000            27.8 ns/op
BenchmarkNumberIsValidRegexp-8   2000000           881 ns/op

[gopherbot]

CL https://golang.org/cl/17199 mentions this issue.