--memory-page-limit accepts negative values and silently wraps to UINT32_MAX instead of rejecting them

Summary

Passing a negative value to --memory-page-limit (e.g. --memory-page-limit=-1) is not rejected as invalid input. Instead, it is silently interpreted as an unsigned 32-bit integer, so -1 becomes 4294967295 (UINT32_MAX). WasmEdge prints an internal warning about the value exceeding the 32-bit page upper bound but continues execution with exit code 0.

Current State

The --memory-page-limit CLI option accepts negative integers without validation. Internally the value appears to be parsed into an unsigned type, causing -1 to wrap around to 4294967295. This is confirmed via:

$ ./wasmedge --memory-page-limit=-1 test.wasm size [error] Memory Instance: Limited 4294967295 page larger than the 32-bit page upper bound 65536. 0 exit code: 0

The command still runs to completion instead of failing with a clear "invalid value" error, unlike how non-numeric input (e.g. --memory-page-limit abc) is correctly rejected with "invalid integer value: abc".

Expected State

A negative value passed to --memory-page-limit should be rejected at the CLI parsing stage with a clear error message (consistent with how non-numeric values like "abc" are already rejected), rather than silently wrapping to a huge unsigned value and only surfacing as an internal runtime warning.

Reproduction steps

1. Build WasmEdge (Debug or Release, no special flags needed to reproduce).
2. Run any valid wasm module with a negative memory page limit:

./wasmedge --memory-page-limit=-1 .wasm

1. Observe that instead of a CLI-level rejection, the tool prints an internal warning ("Limited 4294967295 page larger than the 32-bit page upper bound 65536") and continues execution with exit code 0.

For comparison, run with a non-numeric value:

./wasmedge --memory-page-limit=abc .wasm

This is correctly rejected with "invalid integer value: abc", showing the negative-number case is an inconsistency in the same validation layer.

Any logs you want to share for showing the specific issue

$ ./tools/wasmedge/wasmedge --memory-page-limit=1 test/spec/testSuites/wasm-3.0/memory_size/memory_size.0.wasm size 0 exit code: 0

$ ./tools/wasmedge/wasmedge --memory-page-limit=-1 test/spec/testSuites/wasm-3.0/memory_size/memory_size.0.wasm size [error] Memory Instance: Limited 4294967295 page larger than the 32-bit page upper bound 65536. 0 exit code: 0

$ ./tools/wasmedge/wasmedge --memory-page-limit=abc test/spec/testSuites/wasm-3.0/memory_size/memory_size.0.wasm size invalid integer value: abc

Components

CLI Tools

WasmEdge Version or Commit you used

0.18.0-alpha.1-74-g127d708

Operating system information

Ubuntu (GNU/Linux), GCC/Clang toolchain

Hardware Architecture

x86_64

Appendix

Verified this is not an exploitable memory-allocation issue: calling grow with the wrapped limit in effect does not cause excessive memory allocation, a crash, or a hang (peak RSS ~340MB, exit code 0, completed in under a second). The bug is purely a CLI input-validation gap negative values silently wrap to a huge unsigned value instead of being rejected, unlike other invalid inputs (e.g. non-numeric strings) which are correctly caught.