Skip to content

feat: (CM64) Make realloc signature match the memory's address type#2501

Merged
alexcrichton merged 4 commits intobytecodealliance:mainfrom
michael-weigelt:mwe/realloc
Apr 24, 2026
Merged

feat: (CM64) Make realloc signature match the memory's address type#2501
alexcrichton merged 4 commits intobytecodealliance:mainfrom
michael-weigelt:mwe/realloc

Conversation

@michael-weigelt
Copy link
Copy Markdown
Contributor

@michael-weigelt michael-weigelt commented Apr 23, 2026

This is part of a series of PRs to enable verification of 64bit component model modules. The effort is tracked in #2500.

This PR validates that the realloc canonopt signature matches the memory canonopt address type.

Comment thread tests/cli/component-model/async/task-builtins.wast Outdated
@michael-weigelt michael-weigelt marked this pull request as ready for review April 23, 2026 13:53
@michael-weigelt michael-weigelt requested a review from a team as a code owner April 23, 2026 13:53
@michael-weigelt michael-weigelt requested review from pchickey and removed request for a team April 23, 2026 13:53
Comment on lines +2638 to +2641
let memory_idx = memory.ok_or(BinaryReaderError::new(
"canonical option `realloc` requires the `memory` option",
offset,
))?;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This'll want to defer validation of the signature until after all canonical options have been processed because the realloc option isn't required to show up after the memory option (there's no implicit orderings). What this can do, however, is to require, at the end, that if both realloc and memory are present then there's the correct signature.

To preserve the preexisting behavior of specifying realloc and no memory I think we'll have to continue to validate that it has the i32-based signature, but we should probably make it a first-class spec-level error to specify realloc with memory or basically consider this situation in isolation.

Copy link
Copy Markdown
Contributor Author

@michael-weigelt michael-weigelt Apr 24, 2026

Choose a reason for hiding this comment

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

Paragraph 1: Will do.

To preserve the preexisting behavior of specifying realloc and no memory

Do I understand you correctly that for the present, we must remain backwards compatible, but that you are suggesting to change the spec and move forward at some point? If so, we should gate this new bullet point behind the elephant emoji:

  • if realloc is present then memory must be present

Or we remove it altogether for the present.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Or, if you can point me in the right direction, I can try to

make it a first-class spec-level error to specify realloc with[out] memory

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Hm ok yeah good point. That bullet was actually added by me in WebAssembly/component-model#467 as well, but I botched the implementation in wasm-tools. The implementation in wasm-tools is such that if realloc is required, then memory is also required. The implement needs to be if realloc is specified, then memory is required, however.

Could you file an issue for this and tag this handle-memory-is-None with a fixme pointing to that issue? This PR preserves the preexisting behavior, which is good, but I'll need to sit down and review to see if this is something we can "just change" or whether it's a problem in practice and needs to change more.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Issue: Please edit the text if it's imprecise.
I also refer to it here. By tagging do you mean naming or did you want some sort of label?

Copy link
Copy Markdown
Member

@alexcrichton alexcrichton left a comment

Choose a reason for hiding this comment

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

In the meantime this all looks good so I'll merge

@alexcrichton alexcrichton added this pull request to the merge queue Apr 24, 2026
Merged via the queue into bytecodealliance:main with commit 60cf89d Apr 24, 2026
37 checks passed
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.

2 participants