Reproduced on encoding/json at tip.
http://play.golang.org/p/cXQdZ0SUvD tries to decode a simple array passed over a
net.Conn. This program simulates a client connecting to a server, giving it a json
array, and then waiting for a response without sending further data.
This code causes json.Decoder to deadlock the program. Although it's successfully
decoded a complete array, it tries to read one past the end delimiter, causing another
Read() that will never be fulfilled.
Adding a space after the array closing bracket makes json.Decoder return as expected, as
it had no need to issue any more Reads to see the following byte.
This attempt to read one more byte may be a requirement of the JSON spec (which I'm not
intimate with), or it may be an off-by-one error in the decoder.
The documentation of the decoder states: "The decoder introduces its own buffering
and may read data from r beyond the JSON values requested."
I first read that to mean "Don't use the underlying io.Reader and expect to see the
bytes following the object you just decoded", which is fine and a common caveat of
such decoders. However, I really should have read it as "make sure you have some
data or an EOF after your object, or the decoder may lock up."
If that is the desired behavior, a more strongly worded warning in the docs would be
nice. If that's not desired, well, it's a bug :-).
Which compiler are you using (5g, 6g, 8g, gccgo)?
6g.
Which operating system are you using?
linux.
Which version are you using? (run 'go version')
1.0.2, but behavior confirmed in tip's encoding/json.
The text was updated successfully, but these errors were encountered:
I always read 1 byte past the thing because in general you do need to, such as to find
where a number ends or to make sure that true is not truez (syntax error). However, for
[] and {} and "" we can avoid reading that extra byte and probably should.
by dave@natulte.net:
The text was updated successfully, but these errors were encountered: