Skip to content

Conversation

@BrianLii
Copy link
Contributor

@BrianLii BrianLii commented Feb 9, 2026

Why?

Improve test coverage and robustness for Go int slice primitive serializers.

What does this PR do?

Added new test cases for int, uint, int8, int16, int32, int64, uint16, uint32, uint64 slice serializers in go/fory/slice_primitive_test.go. Tests include large number serialization/deserialization scenarios.

Related issues

@chaokunyang in #3311 (comment)

Does this PR introduce any user-facing change?

  • Does this PR introduce any public API change?
  • Does this PR introduce any binary protocol compatibility change?

@BrianLii BrianLii requested a review from chaokunyang as a code owner February 9, 2026 05:14
t.Run("int_slice_large_numbers", func(t *testing.T) {
slice := []int{1, -2, 3, -4, 2147483647, -2147483648} // Example with large int32 values
if strconv.IntSize == 64 {
slice = []int{1, -2, 3, -4, math.MaxInt64, math.MinInt64} // For int64
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using math.MaxInt64/math.MinInt64 in a []int literal and math.MaxUint64 in a []uint literal still overflows at compile time on 32-bit targets (for example GOARCH=386), even with the IntSize runtime guard. Please switch these literals to arch-sized bounds (math.MaxInt, math.MinInt, math.MaxUint) or build the 64-bit cases without overflowing constants.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants