Skip to content

Use u64 internally to track file offsets instead of usize#2573

Draft
WorldSEnder wants to merge 1 commit into
bytecodealliance:mainfrom
WorldSEnder:u64-position
Draft

Use u64 internally to track file offsets instead of usize#2573
WorldSEnder wants to merge 1 commit into
bytecodealliance:mainfrom
WorldSEnder:u64-position

Conversation

@WorldSEnder

@WorldSEnder WorldSEnder commented Jul 18, 2026

Copy link
Copy Markdown
Contributor

This replaces usize in a lot of places. Besides being a breaking change, this should not impact functionality for most users. Tracking file offset with u64 is the more principled choice.

Fixes #838

Solves a TODO left long ago in the entry code of parse. Most of the places used usize to pass it along to other functions, sinking into Error code for nice error messages, and are thus not sensitive to the data type used. I found two cases that used usize::MAX as a dummy index in a path that called expect() on the eventual error.

Everything else ported rather easily. Not quite happy with the abstractions in offset.rs just now, and the module needs a few doc comments, everything else should work.

This is a work-in-progress as conversion is for now limited to wasmparser, I will check things off as I get to other crates in the repo.

This replaces usize in a lot of places. Besides
being a technically breaking change, this should
not impact functionality.
Solves a TODO left long ago in the entry code
of parse.
@WorldSEnder

Copy link
Copy Markdown
Contributor Author

A lot of consumers seem to hold the entire wasm input in memory, hence these need some ergonomics to convert their offsets back to Range<usize>. Not sure what the best approach is.

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.

wasmparser: usize may not be the most appropriate type for offsets

1 participant