Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use int64 wherever "64-bit integer" is assumed #902

Merged
merged 1 commit into from
Jan 27, 2022
Merged

Conversation

skitt
Copy link
Contributor

@skitt skitt commented Jan 27, 2022

Miller assumes 64-bit integers, but in Go, the int type varies in size
depending on the architecture: 32-bit architectures have int
equivalent to int32. As a result, the supported range of integer
values is greatly reduced on 32-bit architectures compared to what is
suggested by the documentation.

This patch explicitly uses int64 wherever 64-bit integers are
assumed.

Test cases affected by the behaviour of the random generator are
updated to reflect the new values (the existing seed doesn't produce
the same behaviour since the way random values are generated has
changed).

Signed-off-by: Stephen Kitt [email protected]

Miller assumes 64-bit integers, but in Go, the int type varies in size
depending on the architecture: 32-bit architectures have int
equivalent to int32. As a result, the supported range of integer
values is greatly reduced on 32-bit architectures compared to what is
suggested by the documentation.

This patch explicitly uses int64 wherever 64-bit integers are
assumed.

Test cases affected by the behaviour of the random generator are
updated to reflect the new values (the existing seed doesn't produce
the same behaviour since the way random values are generated has
changed).

Signed-off-by: Stephen Kitt <[email protected]>
@skitt
Copy link
Contributor Author

skitt commented Jan 27, 2022

I’m wondering whether unaliasArrayLengthIndex in pkg/bifs/collections.go should also use int64...

@johnkerl
Copy link
Owner

I’m wondering whether unaliasArrayLengthIndex in pkg/bifs/collections.go should also use int64...

@skitt IIUC array indices are the one spot in Go where int (the size of which is processor-dependent) is truly the right thing to do ... I think this is fine ...

P.S. thank you!! :D

@johnkerl johnkerl merged commit d536318 into johnkerl:main Jan 27, 2022
@skitt skitt deleted the int64 branch January 27, 2022 17:08
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.

None yet

2 participants