encoding/json: Unmarshal into struct field or a map does not validate invalid json.Number #14702
Comments
brenol
changed the title
brenol
changed the title
|
This could be fixed by adding the following lines after go/src/encoding/json/decode.go Line 915 in 0cc400f if v.Type() == numberType && !isValidNumber(string(s)) {
d.error(fmt.Errorf("json: invalid number literal, trying to unmarshal %q into Number", item))
}The question is if we really want this as it would kinda break how it currently works. People who currently abuse If you think this would be good to patch I can create a change in gerrit. |
|
@bradfitz any input? Otherwise you can close the issue I guess. |
|
Sorry, this was stuck in the "Unplanned" limbo state which we have since stopped using. I don't believe anybody has looked at this. I'll leave the decision on the bug to @rsc. |
bradfitz
added
the
NeedsDecision
|
Leaving for the next round of JSON work. |
Unmarshal of invalid values, that is a value that is not a number, into fields of type json.Number should fail. Fixes golang#14702
|
Change https://golang.org/cl/195045 mentions this issue: |
Unmarshaling a string into a json.Number should first check that the string is a valid Number. If not, we should fail without decoding it. Fixes golang#14702
|
This change just broke the decoding of |
|
Miha, could you please provide a minimal reproduction that doesn’t work and
we can use that for a test case and perhaps for if/when we make a revert?
Thank you.
…On Tue, Feb 18, 2020 at 12:54 AM Miha Vrhovnik ***@***.***> wrote:
This change just broke the decoding of "field":"" which previously worked
and the use of json.Number was on purpose. I don't have the option to
change the json input I'm getting.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#14702?email_source=notifications&email_token=ABFL3V26WX2IDICKSIWWN4TRDOO4PA5CNFSM4B5NVC22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMBDUAI#issuecomment-587348481>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABFL3V3MXWFSJUT4DEAOC63RDOO4PANCNFSM4B5NVC2Q>
.
|
|
@odeke-em I guess this is the code @mvrhov is trying to use: https://play.golang.org/p/glvZxWT2to8 @mvrhov If you want to support broken input like that you'll have to use json.RawMessage like this: https://play.golang.org/p/iL5Q62g0Lkm |
|
Please continue the discussion in #37308. If you have a sample of the real scenario that broke for you, please add it there. |
since json.Number doesn't allow to decode non-numeric string anymore. golang/go#14702 The Tag.UnmarshalJSON() function is taken from registry-image-resource so it is good that we finally make them consistent. Add more tests to cover this change. Nothing is expected to be broken. Signed-off-by: Rui Yang <ryang@pivotal.io>
since json.Number doesn't allow to decode non-numeric string anymore. golang/go#14702 The Tag.UnmarshalJSON() function is taken from registry-image-resource so it is good that we finally make them consistent. Add more tests to cover this change. Nothing is expected to be broken. Signed-off-by: Rui Yang <ryang@pivotal.io>
For correctness and also because go1.14 is messy when parsing incorrect numbers. For us, when parsing our test events from our file that has `0x0` into a "Number", the resulting slice does not have the right data. ref: golang/go#14702 https://github.com/ethereum/go-ethereum/blob/4bcc0a37ab70cb79b16893556cffdaad6974e7d8/core/types/log.go#L47
* Add name to Events * Allow sol 0.6.8, go1.14 tweaks for json number parsing * allows for solc0.6.8 * go1.14 has changes to json `Number` treatment. This resulted in some of our negative tests returning a different error message due to alphabet input for "bad number" * Change logEntry tx index type to hex uint For correctness and also because go1.14 is messy when parsing incorrect numbers. For us, when parsing our test events from our file that has `0x0` into a "Number", the resulting slice does not have the right data. ref: golang/go#14702 https://github.com/ethereum/go-ethereum/blob/4bcc0a37ab70cb79b16893556cffdaad6974e7d8/core/types/log.go#L47 * Add CustomName to Subscriptions * Fix json for event name * Add tests with event stream name in smartcontract gw * Sub auto-generated summary, accept name from end user * Sets name to whatever is provided by end user, if present in the body * Sets name to `summary`, if one is not provided by end user. summary is auto generated and not returned in the API response * Removed a comment from test file based on review comment
go version)?go1.6 linux/amd64
go env)?linux/amd64
(Use play.golang.org to provide a runnable example, if possible.)
http://play.golang.org/p/8QZq-0vRch
Unmarshal did not accept a invalid JSON as a json.Number, instead, it should raise an error
Unmarshal accepted a invalid JSON as a json.Number and did not raise an error
encoding/json: Encode results in invalid json if json.Number is not a valid number #10281 is the one that actually fixed this issue, however, shouldn't unmarshal should also raise an error? Right now only Marshalling is an raising a error.
@edit
I actually did some further testing and it only happens when Unmarshalling into a struct field, as can be seen in the updated snippet above.
@edit2
It also happens when using map[string]json.Number and I have updated the test case accordingly.
The text was updated successfully, but these errors were encountered: