encoding/json: json.Number accepts quoted values by default

[vearutop]

What version of Go are you using (go version)?

$ go version
go version go1.13 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/viacheslav.poturaev/Library/Caches/go-build"
GOENV="/Users/viacheslav.poturaev/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY="github.com/hellofresh"
GONOSUMDB="github.com/hellofresh"
GOOS="darwin"
GOPATH="/Users/viacheslav.poturaev/go"
GOPRIVATE="github.com/hellofresh"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.13/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.13/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/h7/7qg3nbt91bb6mgk2xtqqpwc40000gp/T/go-build850653985=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I've decoded a JSON value of "123" into json.Number.
https://play.golang.org/p/9Nwjn3rBFxI

What did you expect to see?

I've expected to see an error.

What did you see instead?

I've seen a successful result and an int64 value of 123 accessible with .Int64().

I could not find any documentation that json.Number accepts quoted string values by default and was expecting the opposite (as per "being precise" motivation expressed in #22463 (comment)).

Not sure if this is a documentation or implementation issue.

[bcmills]

Looks like the Number validation changed very recently (in CL 195045; see #14702).

Is this still reproducible using gotip?

[vearutop]

Same behavior with go version devel +361ab73 Mon Sep 23 05:57:54 2019 +0000 darwin/amd64.

[vearutop]

I think such behavior is historical, at least in go1.12 it is still same. Maybe the documentation has to be more explicit.

[bcmills]

CC @dsnet @bradfitz @mvdan

[bcmills]

Thanks for checking.

[mvdan]

Some changes related to json.Number from @breml were merged recently, perhaps he has thoughts.

Without looking deeply into the issue, remember that json.Number is a string type underneath, so perhaps this was meant to be supported by design.

[kentquirk]

json.Number is a string; the Int64() and Float64() methods return an error if the conversion is invalid.

I can't think of why this would need to exist unless it were intended to work this way.

To force conformance to a specific type in JSON, you could use the type directly instead of json.Number.

I think this could be clarified in documentation but changing the behavior would cause previously-working code to break.

[vearutop]

@kentquirk being a string for raw JSON value is ok, being a quoted string is less ok.

As you would not expect the following code to return valid integer:

strconv.Atoi(`"123"`)

JSON.org defines values as:

A value can be a string in double quotes, or a number, or true or false or null, or an object or an array.

Which makes an explicit difference between double-quoted string and number.

The documentation says:

A Number represents a JSON number literal.

I also think this issue in likely about clarifying documentation given the potential impact of behavior change. Though maybe it would make sense to revisit behavior for Go 2.

[breml]

I quickly checked the code and I have come to the following conclusions:

• This has worked for a long time, the relevant lines (https://github.com/golang/go/blame/c1000c500cb4cec2991f8c1924cd5fff05279658/src/encoding/json/decode.go#L951 and https://github.com/golang/go/blame/c1000c500cb4cec2991f8c1924cd5fff05279658/src/encoding/json/decode.go#L955) have been unchanged since more than 9 years.
• This issue can be seen as related to the issue I fixed some days ago (encoding/json: Unmarshal into struct field or a map does not validate invalid json.Number #14702).
• The decoding of a quoted numerical value into json.Number should (in my opinion) only work, if the option ,string is set in the struct tags.
• My change c1000c5 did not alter this behavior.
• But the condition I inserted in the above mentioned commit could be extended to handle this case as well if the block https://github.com/golang/go/blame/c1000c500cb4cec2991f8c1924cd5fff05279658/src/encoding/json/decode.go#L952-L954 would be changed to:

if v.Type() == numberType && (!fromQuoted || !isValidNumber(string(s))) {
	return fmt.Errorf("json: invalid number literal, trying to unmarshal %q into Number", item)
}

• I also quickly checked the test cases in decode_test.go and I could not find a test case testing this case, so I assume, it is not intended behavior.
• Respective test cases could be easily added after the encoding/json: Unmarshal into struct field or a map does not validate invalid json.Number #14702 related test cases

  go/src/encoding/json/decode_test.go

  Lines 952 to 982 in c1000c5

  	// #14702
  	{
  	in: `invalid`,
  	ptr: new(Number),
  	err: &SyntaxError{
  	msg: "invalid character 'i' looking for beginning of value",
  	Offset: 1,
  	},
  	},
  	{
  	in: `"invalid"`,
  	ptr: new(Number),
  	err: fmt.Errorf("json: invalid number literal, trying to unmarshal %q into Number", `"invalid"`),
  	},
  	{
  	in: `{"A":"invalid"}`,
  	ptr: new(struct{ A Number }),
  	err: fmt.Errorf("json: invalid number literal, trying to unmarshal %q into Number", `"invalid"`),
  	},
  	{
  	in: `{"A":"invalid"}`,
  	ptr: new(struct {
  	A Number `json:",string"`
  	}),
  	err: fmt.Errorf("json: invalid use of ,string struct tag, trying to unmarshal %q into json.Number", `invalid`),
  	},
  	{
  	in: `{"A":"invalid"}`,
  	ptr: new(map[string]Number),
  	err: fmt.Errorf("json: invalid number literal, trying to unmarshal %q into Number", `"invalid"`),
  	},