Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 97187c70fb8727a668d979e6314a9a605e31d605
https://github.com/WebKit/WebKit/commit/97187c70fb8727a668d979e6314a9a605e31d605
Author: Cole Carley <[email protected]>
Date: 2026-07-24 (Fri, 24 Jul 2026)
Changed paths:
M JSTests/wasm/js-api/table.js
A JSTests/wasm/stress/table64-initial-truncation.js
M JSTests/wasm/v8/regress/regress-1114005.js
M
LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/table64.wast.js-expected.txt
M
LayoutTests/imported/w3c/web-platform-tests/wasm/core/table.wast.js-expected.txt
M Source/JavaScriptCore/wasm/WasmSectionParser.cpp
Log Message:
-----------
[Memory64] Allow Wasm modules with an oversized initial table size to compile
https://bugs.webkit.org/show_bug.cgi?id=320132
rdar://183070350
Reviewed by Marcus Plutowski.
LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/table64.wast.js
test #10 and #33 are failing because modules with tables with initial sizes
larger than Wasm::maxTableEntries fail to compile.
To fix this, I removed the compile-time check that is causing the failure.
Once the check is gone, the uint64_t initial is silently narrowed when
constructing TableInformation, so a value could overflow a uint32_t and wrap to
a
small, valid-looking length.
Instead of rejecting a large initial at parse time, clamp the value to
maxTableEntries when narrowing it to the stored uint32_t. Out-of-range
declarations therefore stay out of range and are still rejected by
Table::tryCreate() at instantiation.
* JSTests/wasm/stress/table64-initial-truncation.js: Added.
(leb128):
(moduleBytesWithTableInitial):
*
LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/table64.wast.js-expected.txt:
* Source/JavaScriptCore/wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseTableHelper):
Canonical link: https://commits.webkit.org/317888@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
