rlp: add back Iterator.Count, with fixes#33841
Merged
Merged
Conversation
I removed Iterator.Count in ethereum#33840, because it appeared to be unused and did not provide the documented invariant: the returned Count should always be an upper bound on the number of iterations allowed by Next(). In order to make Count work, the semantics of CountValues has to change to return the number of items up and including the invalid one. I have reviewed all callsites of CountValues to assess if changing this is safe. There aren't that many, and the only call that doesn't check the error and return is in the trie node parser, trie.decodeNodeUnsafe. There, we distinguish the node type based on the number of items, and it previously returned an error for item count zero. In order to avoid any potential issue that could result from this change, I'm adding an error check in that function.
sduchesneau
pushed a commit
to streamingfast/go-ethereum
that referenced
this pull request
Apr 7, 2026
I removed `Iterator.Count` in ethereum#33840, because it appeared to be unused and did not provide the documented invariant: the returned count should always be an upper bound on the number of iterations allowed by `Next`. In order to make `Count` work, the semantics of `CountValues` has to change to return the number of items up and including the invalid one. I have reviewed all callsites of `CountValues` to assess if changing this is safe. There aren't that many, and the only call that doesn't check the error and return is in the trie node parser, `trie.decodeNodeUnsafe`. There, we distinguish the node type based on the number of items, and it previously returned an error for item count zero. In order to avoid any potential issue that could result from this change, I'm adding an error check in that function, though it isn't necessary.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I removed
Iterator.Countin #33840, because it appeared to be unused and did not provide the documented invariant: the returned count should always be an upper bound on the number of iterations allowed byNext.In order to make
Countwork, the semantics ofCountValueshas to change to return the number of items up and including the invalid one. I have reviewed all callsites ofCountValuesto assess if changing this is safe. There aren't that many, and the only call that doesn't check the error and return is in the trie node parser,trie.decodeNodeUnsafe. There, we distinguish the node type based on the number of items, and it previously returned an error for item count zero. In order to avoid any potential issue that could result from this change, I'm adding an error check in that function, though it isn't necessary.