Integer overflow on 32bit systems #36
Description
Recently I updated the packaging of msgp for Debian, updating it to version 1.4.0. One of its tests exposes an integer overflow in Reader.Next() on 32bit systems:
--- FAIL: FuzzReader/seed#1090 (0.00s)
panic: runtime error: slice bounds out of range [:-148368575] [recovered]
panic: runtime error: slice bounds out of range [:-148368575]
goroutine 1442 [running]:
testing.tRunner.func1.2({0x82830a0, 0x10346110})
/usr/lib/go-1.24/src/testing/testing.go:1734 +0x283
testing.tRunner.func1()
/usr/lib/go-1.24/src/testing/testing.go:1737 +0x415
panic({0x82830a0, 0x10346110})
/usr/lib/go-1.24/src/runtime/panic.go:792 +0x103
github.com/philhofer/fwd.(*Reader).Next(0xfbc80f0, 0xf7281341)
/home/gibmat/pkgs/golang-github-tinylib-msgp-1.4.0/obj-i686-linux-gnu/src/github.com/philhofer/fwd/reader.go:293 +0xc4
github.com/tinylib/msgp/msgp.(*Reader).CopyNext(0xfbc80c0, {0x82e9fd0, 0x844d240})
/home/gibmat/pkgs/golang-github-tinylib-msgp-1.4.0/obj-i686-linux-gnu/src/github.com/tinylib/msgp/msgp/read.go:181 +0x88
github.com/tinylib/msgp/msgp.FuzzReader.func1(0x9807208, {0x10592310, 0xa, 0x10})
/home/gibmat/pkgs/golang-github-tinylib-msgp-1.4.0/obj-i686-linux-gnu/src/github.com/tinylib/msgp/msgp/fuzz_test.go:40 +0x110
reflect.Value.call({0x825ff20, 0x82a7ea4, 0x13}, {0x829507a, 0x4}, {0x1058c198, 0x2, 0x2})
/usr/lib/go-1.24/src/reflect/value.go:584 +0x97f
reflect.Value.Call({0x825ff20, 0x82a7ea4, 0x13}, {0x1058c198, 0x2, 0x2})
/usr/lib/go-1.24/src/reflect/value.go:368 +0x7f
testing.(*F).Fuzz.func1.1(0x9807208)
/usr/lib/go-1.24/src/testing/fuzz.go:340 +0x2cb
testing.tRunner(0x9807208, 0x98b60a0)
/usr/lib/go-1.24/src/testing/testing.go:1792 +0x119
created by testing.(*F).Fuzz.func1 in goroutine 251
/usr/lib/go-1.24/src/testing/fuzz.go:327 +0x559
FAIL github.com/tinylib/msgp/msgp 2.815s
This is caused by the field n in the Reader struct being defined as an int; interestingly inputOffset is defined as an int64 in that same struct. Changing n to be an int64 would fix the issue, although I'm not sure how far out the changes would ripple in changing method signatures or needing to deliberately cast to int64s at various points in the code. A quick-n-dirty approach seemed to work pretty well, with the exception of the various io interfaces that specify an int.
I know 32bit systems are becoming rarer, and Debian is deprecating some support, but armhf is still a release architecture and I'd like to be able to provide msgp on all architectures.