fix: enforce int64 for large integer values in tests

[arthurbdiniz]

The bug arises from the use of generic integer types (int) in test cases involving large numerical values that exceed the range of a 32-bit integer.

In Go, the size of the int type depends on the platform, this behavior causes inconsistencies when handling large integers, such as -9223372036854775808 and 9007199254740993.

On 32-bit systems, these values cannot be represented correctly as int, leading to potential overflow or truncation errors. By explicitly using the int64 type in the affected test cases, the code ensures proper handling and representation of large integers across all platforms, avoiding platform-specific bugs and improving the reliability of the tests.

Reproduce

Run tests setting GOARCH to 386.

GOARCH=386 GOOS=linux go test -vet=off -v -p 2 sigs.k8s.io/yaml sigs.k8s.io/yaml/goyaml.v2 sigs.k8s.io/yaml/goyaml.v3


# sigs.k8s.io/yaml/goyaml.v2_test [sigs.k8s.io/yaml/goyaml.v2.test]
goyaml.v2/decode_test.go:134:33: cannot use -9223372036854775808 (untyped int constant) as int value in map literal (overflows)
# sigs.k8s.io/yaml [sigs.k8s.io/yaml.test]
./yaml_test.go:186:50: cannot use math.MaxInt64 (untyped int constant 9223372036854775807) as int value in argument to fmt.Sprintf (overflows)
./yaml_test.go:415:16: cannot use 9007199254740993 (untyped int constant) as int value in struct literal (overflows)
FAIL	sigs.k8s.io/yaml [build failed]
FAIL	sigs.k8s.io/yaml/goyaml.v2 [build failed]
# sigs.k8s.io/yaml/goyaml.v3_test [sigs.k8s.io/yaml/goyaml.v3.test]
goyaml.v3/decode_test.go:180:33: cannot use -9223372036854775808 (untyped int constant) as int value in map literal (overflows)
FAIL	sigs.k8s.io/yaml/goyaml.v3 [build failed]
FAIL

---

Changes:

• Switched expected values from map[string]interface{} to map[string]int64
  to ensure type consistency and avoid type mismatch failures in DeepEquals.
• Ensured literal -9223372036854775808 is treated safely as an int64 to
  prevent compile-time constant overflow on 32-bit platforms.
• Updated Marshal and Unmarshal tests to explicitly use int64 when working
  with large integer constants that exceed int32 range.

These changes address potential issues with integer overflow and ensure compatibility across platforms with differing integer size representations.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: arthurbdiniz / name: Arthur Diniz (909bfc4)

[k8s-ci-robot]

Welcome @arthurbdiniz!

It looks like this is your first PR to kubernetes-sigs/yaml 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/yaml has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[arthurbdiniz]

Added an amended commit to my fork and for some reason it was not synced here.

master...arthurbdiniz:yaml:fix/tests-32bit-architectures

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle rotten
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[arthurbdiniz]

/remove-lifecycle rotten

[BenTheElder]

/cc @liggitt @dims

[BenTheElder]

NOTE: the upstream https://github.com/go-yaml/yaml was archived april 1st 2025 (yes april first ... https://github.com/go-yaml/yaml#this-project-is-unmaintained)

So we don't have much reason to worry about reconciling diffs with upstream.

/lgtm

[liggitt]

/approve

[arthurbdiniz]

Added an amended commit to my fork and for some reason it was not synced here.

master...arthurbdiniz:yaml:fix/tests-32bit-architectures

As peer this message for some reason the changes on my forked branch did not sync automatically. So I had sync it.

Sorry for dropping the approval.

[ccoVeille]

The "bug" occurs on yaml/go-yaml too

GOARCH=386 go test ./...
# go.yaml.in/yaml/v4_test [go.yaml.in/yaml/v4.test]
./decode_test.go:247:25: cannot use -9223372036854775808 (untyped int constant) as int value in map literal (overflows)

So I opened

• tests don't pass of a i386 arch yaml/go-yaml#128
• Fix int64 minimum value handling in tests for cross-architecture compatibility yaml/go-yaml#129

[dims]

@ccoVeille we recently ran across a similar problem in otel (not exactly the same, but similar). we could strengthen our testing similarly perhaps?

• https://github.com/open-telemetry/opentelemetry-go-instrumentation/blob/67d3c3ff5b1b239b29530fcd2f35a9f1d70650a9/.github/workflows/checks.yml#L133-L163
• Fix 32bit arch int overflow in sdk open-telemetry/opentelemetry-go-instrumentation#2810
• [future][dependencies] go.opentelemetry.io/auto/sdk updates breaks kind-master-dependencies job kubernetes/kubernetes#134066

[ccoVeille]

I feel like this comment was for @arthurbdiniz

He owns the current PR.

[ingydotnet]

@arthurbdiniz would you mind opening a PR at https://github.com/yaml/go-yaml/pulls
That repo is now the upstream for this repo and https://github.com/kubernetes/kubernetes/
Target the main branch and we can talk about it also going into v3 and v2.
If you don't have time, say so, and we can grab it ourselves.

Apologies. Misunderstood.

@ccoVeille has opened this as yaml/go-yaml#129

[arthurbdiniz]

I think instead of changing the interface to int64 it's possible to create a function to return the correct int size.

func intOrInt64(v int64) interface{} {
	// On 64-bit systems, large numbers will be int
	// On 32-bit systems, they will remain int64
	if strconv.IntSize == 64 {
		return int(v)
	}
	return v
}

Here is the reference for the full patch.

0001-Fix-int64-minimum-value-handling-in-tests-for-cross-.patch

Now that goyaml.v2 and goyaml.v3 folders are just a reference to go.yaml.in/yaml/* that function can be incorporated at yaml/go-yaml#129 if make sense.

cc @ccoVeille

[arthurbdiniz]

Some yaml_test.go test are still failing so I updated this PR to fix that.

[ccoVeille]

I think instead of changing the interface to int64 it's possible to create a function to return the correct int size.

func intOrInt64(v int64) interface{} {
	// On 64-bit systems, large numbers will be int
	// On 32-bit systems, they will remain int64
	if strconv.IntSize == 64 {
		return int(v)
	}
	return v
}

Here is the reference for the full patch.

0001-Fix-int64-minimum-value-handling-in-tests-for-cross-.patch

Now that goyaml.v2 and goyaml.v3 folders are just a reference to go.yaml.in/yaml/* that function can be incorporated at yaml/go-yaml#129 if make sense.

cc @ccoVeille

I'm hesitant with this.

I would prefer a type that is defined by arch with build tags, but it would be overkill. Your solution works, but honestly I'm unsure there is a need for it.

Your solution to use int64 everywhere sounds a sane and simpler approach.

So I'm fine with it.

[liggitt]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: arthurbdiniz, ccoVeille, liggitt

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [liggitt]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment