The TestZip64 fails and the TestZip64EdgeCase panics when run on openbsd/386 and openbsd/arm (and I would hazard a guess that they fail on any 32-bit architecture) - the output from go test -test.v archive/zip is:
...
=== CONT TestZip64EdgeCase
--- FAIL: TestZip64 (12.82s)
zip_test.go:574: read: unexpected EOF
=== CONT TestZip64ManyRecords/uint16max-1_NoZip64
--- FAIL: TestZip64EdgeCase (12.83s)
panic: runtime error: slice bounds out of range [recovered]
panic: runtime error: slice bounds out of range
goroutine 274 [running]:
testing.tRunner.func1(0x3ac125a0)
/home/joel/src/go/src/testing/testing.go:827 +0x308
panic(0x815d200, 0x8272ae0)
/home/joel/src/go/src/runtime/panic.go:522 +0x162
archive/zip.(*rleBuffer).ReadAt(0x3b39c040, 0x3b3a8000, 0x400, 0x400, 0x26, 0x0, 0x1f, 0x81a16a7, 0x0)
/home/joel/src/go/src/archive/zip/zip_test.go:194 +0x20a
io.(*SectionReader).Read(0x3ad7e0a0, 0x3b3a8000, 0x400, 0x400, 0x8051813, 0x3ac0e3d8, 0x8)
/home/joel/src/go/src/io/io.go:475 +0xb7
archive/zip.(*checksumReader).Read(0x3acee090, 0x3b3a8000, 0x400, 0x400, 0x804fafd, 0x816d440, 0x804fb63)
/home/joel/src/go/src/archive/zip/reader.go:198 +0x4a
io.ReadAtLeast(0x171cb098, 0x3acee090, 0x3b3a8000, 0x400, 0x400, 0x400, 0x0, 0x3ac12280, 0x40000000)
/home/joel/src/go/src/io/io.go:310 +0x6e
io.ReadFull(...)
/home/joel/src/go/src/io/io.go:329
archive/zip.testZip64(0x81a6ae0, 0x3ac125a0, 0xfffffffb, 0x0, 0x3ac106c0)
/home/joel/src/go/src/archive/zip/zip_test.go:572 +0x865
archive/zip.TestZip64EdgeCase(0x3ac125a0)
/home/joel/src/go/src/archive/zip/zip_test.go:264 +0x52
testing.tRunner(0x3ac125a0, 0x81846b8)
/home/joel/src/go/src/testing/testing.go:862 +0x91
created by testing.(*T).Run
/home/joel/src/go/src/testing/testing.go:913 +0x2ac
FAIL archive/zip 13.711s
I would suspect an int type being the cause (wraparound with int32 vs int64), however I've not had time to dig further (it does appear that it is likely just the test code that is failing, not the actual archive/zip code itself...).
The TestZip64 fails and the TestZip64EdgeCase panics when run on openbsd/386 and openbsd/arm (and I would hazard a guess that they fail on any 32-bit architecture) - the output from
go test -test.v archive/zipis:... === CONT TestZip64EdgeCase --- FAIL: TestZip64 (12.82s) zip_test.go:574: read: unexpected EOF === CONT TestZip64ManyRecords/uint16max-1_NoZip64 --- FAIL: TestZip64EdgeCase (12.83s) panic: runtime error: slice bounds out of range [recovered] panic: runtime error: slice bounds out of range goroutine 274 [running]: testing.tRunner.func1(0x3ac125a0) /home/joel/src/go/src/testing/testing.go:827 +0x308 panic(0x815d200, 0x8272ae0) /home/joel/src/go/src/runtime/panic.go:522 +0x162 archive/zip.(*rleBuffer).ReadAt(0x3b39c040, 0x3b3a8000, 0x400, 0x400, 0x26, 0x0, 0x1f, 0x81a16a7, 0x0) /home/joel/src/go/src/archive/zip/zip_test.go:194 +0x20a io.(*SectionReader).Read(0x3ad7e0a0, 0x3b3a8000, 0x400, 0x400, 0x8051813, 0x3ac0e3d8, 0x8) /home/joel/src/go/src/io/io.go:475 +0xb7 archive/zip.(*checksumReader).Read(0x3acee090, 0x3b3a8000, 0x400, 0x400, 0x804fafd, 0x816d440, 0x804fb63) /home/joel/src/go/src/archive/zip/reader.go:198 +0x4a io.ReadAtLeast(0x171cb098, 0x3acee090, 0x3b3a8000, 0x400, 0x400, 0x400, 0x0, 0x3ac12280, 0x40000000) /home/joel/src/go/src/io/io.go:310 +0x6e io.ReadFull(...) /home/joel/src/go/src/io/io.go:329 archive/zip.testZip64(0x81a6ae0, 0x3ac125a0, 0xfffffffb, 0x0, 0x3ac106c0) /home/joel/src/go/src/archive/zip/zip_test.go:572 +0x865 archive/zip.TestZip64EdgeCase(0x3ac125a0) /home/joel/src/go/src/archive/zip/zip_test.go:264 +0x52 testing.tRunner(0x3ac125a0, 0x81846b8) /home/joel/src/go/src/testing/testing.go:862 +0x91 created by testing.(*T).Run /home/joel/src/go/src/testing/testing.go:913 +0x2ac FAIL archive/zip 13.711sI would suspect an int type being the cause (wraparound with int32 vs int64), however I've not had time to dig further (it does appear that it is likely just the test code that is failing, not the actual archive/zip code itself...).