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

test: add test for unint64 overflow on limit #5713

Merged
merged 6 commits into from
Jan 24, 2024
Merged

Conversation

DimitrisJim
Copy link
Contributor

Description

Wrap around is guaranteed in this case, ref https://go.dev/ref/spec#Integer_overflow. For signed ints this is also deterministic apparently.

closes: #XXXX

Commit Message / Changelog Entry

test: add test that asserts values after limit wraps around.

see the guidelines for commit messages. (view raw markdown for examples)


Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

  • Targeted PR against the correct branch (see CONTRIBUTING.md).
  • Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • Code follows the module structure standards and Go style guide.
  • Wrote unit and integration tests.
  • Updated relevant documentation (docs/) or specification (x/<module>/spec/).
  • Added relevant godoc comments.
  • Provide a commit message to be used for the changelog entry in the PR description for review.
  • Re-reviewed Files changed in the Github PR explorer.
  • Review Codecov Report in the comment section below once CI passes.

Comment on lines +825 to +828
// Nothing should be pruned, by passing in a limit of math.MaxUint64, overflow occurs
// when initializing end to pruningSequenceStart + limit. This results in end always being
// equal to start - 1 and thereby not entering the for loop.
// We expect 10 acks, 10 receipts and pruningSequenceStart == 1 (loop not entered).
Copy link
Contributor

Choose a reason for hiding this comment

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

crazy, so it doesn't panic, it just wraps around. I guess by construction this is safe. Should we add an in-line comment in the code in case someone tries to refactor it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

absolutely! Added a small note, feel free (you or anyone else) to expand on my dry-ness 😅

Copy link
Contributor

@colin-axner colin-axner left a comment

Choose a reason for hiding this comment

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

Thank you @DimitrisJim !!!

Copy link
Contributor

@crodriguezvega crodriguezvega left a comment

Choose a reason for hiding this comment

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

Thanks for checking this!

@DimitrisJim DimitrisJim enabled auto-merge (squash) January 24, 2024 21:16
@DimitrisJim DimitrisJim merged commit bd27f58 into main Jan 24, 2024
60 of 62 checks passed
@DimitrisJim DimitrisJim deleted the jim/test-limit-overflow branch January 24, 2024 21:31
@damiannolan
Copy link
Member

Awesome @DimitrisJim, nice one!

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.

4 participants