It looks like v1.9.0 increased test coverage, and on 32bit systems (like armhf), the int and uint tests fail because those types are too small to hold some of the values:
--- FAIL: TestNumber/int64/#14/Value/Pointer/ToE (0.01s)
number_test.go:381:
error:
got non-nil error
got:
e`unable to cast "9223372036854775807" of type string to int64: strconv.ParseInt: parsing "9223372036854775807": value out of range`
stack:
/home/gibmat/cast/number_test.go:381
c.Assert(err, qt.IsNil)
--- FAIL: TestNumber/uint64/#14/Value/Pointer/ToTypeE (0.01s)
number_test.go:367:
error:
got non-nil error
got:
e`unable to cast "18446744073709551615" of type string to uint64: strconv.ParseUint: parsing "18446744073709551615": value out of range`
stack:
/home/gibmat/cast/number_test.go:367
c.Assert(err, qt.IsNil)
I looked at the code, and explicitly telling strconv.Parse{Int,Uint} to use a full 64bit variable allows the tests to pass on both 32bit and 64bit systems. However, I don't know if this might have other consequence if trying to cast an 8, 16, or 32bit variable.
diff --git a/number.go b/number.go
index a58dc4d..a4c4576 100644
--- a/number.go
+++ b/number.go
@@ -405,7 +405,7 @@ func parseNumber[T Number](s string) (T, error) {
}
func parseInt[T integer](s string) (T, error) {
- v, err := strconv.ParseInt(trimDecimal(s), 0, 0)
+ v, err := strconv.ParseInt(trimDecimal(s), 0, 64)
if err != nil {
return 0, err
}
@@ -414,7 +414,7 @@ func parseInt[T integer](s string) (T, error) {
}
func parseUint[T unsigned](s string) (T, error) {
- v, err := strconv.ParseUint(strings.TrimLeft(trimDecimal(s), "+"), 0, 0)
+ v, err := strconv.ParseUint(strings.TrimLeft(trimDecimal(s), "+"), 0, 64)
if err != nil {
return 0, err
}
It looks like v1.9.0 increased test coverage, and on 32bit systems (like armhf), the
intanduinttests fail because those types are too small to hold some of the values:I looked at the code, and explicitly telling
strconv.Parse{Int,Uint}to use a full 64bit variable allows the tests to pass on both 32bit and 64bit systems. However, I don't know if this might have other consequence if trying to cast an 8, 16, or 32bit variable.