json: exclude panics from duplicate keys about go-fuzz-corpus HOT 5 OPEN

Adding my comment from golang/go#31309:

About this, I'm not sure we should consider this OK for the parser: what happens is that the field O **int is first filled with a value, then the last pointer of the chain is niled, while on the second unmarshal the first pointer of the chain is niled, hence the deep-equal failure.

This is valid behavior, but I find it inconsistent somewhat: I would expected both payloads to end-up with the same level of pointer being nil, not being dependent on the previous value of the field.

from go-fuzz-corpus.

Discussion of how the json parser should handle particular inputs should probably happen in a new issue in the Go repo. (Sorry you keep getting bounced around.)

from go-fuzz-corpus.

I expected it. I just wanted to keep this issue updated (or at least linked) because the project here spans so much it's a little hard to keep track of everything (I've spend half my free time yesterday bouncing around while discovering :P ).

from go-fuzz-corpus.

I didn't see a new issue get filed, so just in case, cc @mvdan, who probably has opinions about the json parser's behavior.

from go-fuzz-corpus.

I don't have an opinion unless someone opens an issue on the tracker with a specific problem or proposed change ;)

The decoder could certainly be taught an option to reject duplicate keys on maps and structs, though. That's the kind of thing I had in mind to fix golang/go#14750 sometime in 1.14.

from go-fuzz-corpus.