encoder: More unexpected EOF handling
Continuing 995fce81 I've decided to rework unexpected EOF testing to run on truncated versions of all inputs we already have. This uncovered the following: - if an individual op decoder returns err=io.EOF - this is unexpected and should be turned into io.ErrUnexpectedEOF. If we do not do it shows as e.g. ogorek_test.go:91: int: no ErrUnexpectedEOF on [:1] truncated stream: v = <nil> err = &errors.errorString{s:"EOF"} - there was a potential buffer overrun panic in loadString - the code there did not have proper check for line rest length after initial ". The panic looks like this: --- FAIL: TestDecode (0.00s) panic: runtime error: slice bounds out of range [recovered] panic: runtime error: slice bounds out of range goroutine 7 [running]: testing.tRunner.func1(0xc4200725b0) /home/kirr/src/tools/go/go/src/testing/testing.go:624 +0x267 panic(0x5368c0, 0x603020) /home/kirr/src/tools/go/go/src/runtime/panic.go:489 +0x26e github.com/kisielk/og-rek.(*Decoder).loadString(0xc420063428, 0xc42000e153, 0x0) /home/kirr/src/wendelin/neo/g.neo/src/github.com/kisielk/og-rek/ogorek.go:478 +0x22d github.com/kisielk/og-rek.Decoder.Decode(0xc42012fbc0, 0x6248e8, 0x0, 0x0, 0xc42013ac60, 0x0, 0x0, 0x5f2480, 0xc42000e150) /home/kirr/src/wendelin/neo/g.neo/src/github.com/kisielk/og-rek/ogorek.go:166 +0xa83 github.com/kisielk/og-rek.TestDecode(0xc4200725b0) /home/kirr/src/wendelin/neo/g.neo/src/github.com/kisielk/og-rek/ogorek_test.go:89 +0x26c7 testing.tRunner(0xc4200725b0, 0x567618) /home/kirr/src/tools/go/go/src/testing/testing.go:659 +0x98 created by testing.(*T).Run /home/kirr/src/tools/go/go/src/testing/testing.go:701 +0x2df exit status 2 and can be triggered by single-character " input. - we also turn what was previously an "insecure string" into unexpected EOF. The reason here is: code could not find " in the end of the string. This can be for 2 reasons: 1. EOF was reached, or 2. EOL (end of line) was reached unfortunately since we are currently using bufio.Buffer.ReadLine() which does not indicate whether EOL was there or not and strips it from result, we cannot distinguish above cases and properly report "insecure string" in 2 case. However unexpected EOF even for #2 seems a bit reasonable, so I think the change should be ok.
Showing