Description
Description
Currently, the interpreter stacks in TinyWasm (e.g., for values and control frames) grow dynamically via Rust Vec::push operations without enforcing explicit size limits. While this approach works well on desktop systems, it can lead to allocation failures and panics on embedded targets, where memory is limited and heap growth is constrained.
This creates a situation where a Wasm module with certain characteristics can cause the interpreter to panic, effectively crashing the entire program—an issue in embedded environments and one that contradicts the core safety and isolation guarantees of Wasm.
This issue proposes enabling optional, user-defined limits on the interpreter stacks. Specifically:
- Users should be able to specify maximum sizes for the stacks used by the interpreter.
- If configured, these limits would be checked at runtime when pushing to the respective stack.
- If a push operation would exceed the configured limit, the interpreter should return an error (instead of pushing into the vector and risking a panic due to an allocation error).
Backwards Compatibility and Performance
This feature can be introduced in a backwards-compatible and zero-cost way for users who do not need it:
- The limit checks could be feature-gated, ensuring no additional runtime overhead when the feature is disabled.
- Defaults can retain the current behavior, with no limits imposed unless explicitly configured.