Reproducer: https://play.golang.org/p/q5rwBgfs6_0

The docs say:

If the input is at EOF, Decode returns io.EOF and does not modify e.

I take this to mean that, if the input reader gives 0 bytes and io.EOF, then Decode returns io.EOF without modifying any data. That's fine.

However, as you can see from the playground link, right now the decoder can return io.EOF if the input is cut off at specific non-zero offsets. In particular, if the input has messages for type specifications, but zero messages for data. That triggers the "zero input" io.EOF case documented above, even though we have read some messages.

I encountered this in a real program where the input was being corrupted, so I ended up with non-zero bytes of gob that made the decoder error. I was very surprised to see that, sometimes, the error was io.EOF instead of io.ErrUnexpectedEOF. I narrowed it down to this edge case and reproducer.

I'm going to send a CL with a test and a fix. Another possibility is to modify the docs to clarify the current behavior without changing it. I would personally not agree with that solution, because it seems odd for a decoder to parse a non-zero amount of bytes, hit EOF before it actually decodes any data, and simply give the user an io.EOF error. Especially because Encode always writes a data item, so Decode should require a data item if it can read a non-zero amount of bytes.

In any case, if we wanted to instead document the existing behavior, we could insteady say:

If the input hits EOF before a data item, Decode returns io.EOF and does not modify e.

cc @robpike as per https://dev.golang.org/owners