NEW 234967
JSC::Wasm::setWasmTableElement() falls through ASSERT_NOT_REACHED()
https://bugs.webkit.org/show_bug.cgi?id=234967
Summary JSC::Wasm::setWasmTableElement() falls through ASSERT_NOT_REACHED()
David Kilzer (:ddkilzer)
Reported 2022-01-07 10:38:47 PST
JSC::Wasm::setWasmTableElement() falls through ASSERT_NOT_REACHED(). The functions should return `false` after both ASSERT_NOT_REACHED() statements rather than falling through and returning `true`. static bool setWasmTableElement(Instance* instance, unsigned tableIndex, uint32_t index, EncodedJSValue encValue) { ASSERT(tableIndex < instance->module().moduleInformation().tableCount()); if (index >= instance->table(tableIndex)->length()) return false; JSValue value = JSValue::decode(encValue); if (instance->table(tableIndex)->type() == Wasm::TableElementType::Externref) instance->table(tableIndex)->set(index, value); else if (instance->table(tableIndex)->type() == Wasm::TableElementType::Funcref) { WebAssemblyFunction* wasmFunction; WebAssemblyWrapperFunction* wasmWrapperFunction; if (isWebAssemblyHostFunction(instance->owner<JSObject>()->vm(), value, wasmFunction, wasmWrapperFunction)) { ASSERT(!!wasmFunction || !!wasmWrapperFunction); if (wasmFunction) instance->table(tableIndex)->asFuncrefTable()->setFunction(index, jsCast<JSObject*>(value), wasmFunction->importableFunction(), &wasmFunction->instance()->instance()); else instance->table(tableIndex)->asFuncrefTable()->setFunction(index, jsCast<JSObject*>(value), wasmWrapperFunction->importableFunction(), &wasmWrapperFunction->instance()->instance()); } else if (value.isNull()) instance->table(tableIndex)->clear(index); else ASSERT_NOT_REACHED(); } else ASSERT_NOT_REACHED(); return true; } See Source/JavaScriptCore/wasm/WasmOperations.cpp.
Attachments
Radar WebKit Bug Importer
Comment 1 2022-01-07 10:39:05 PST
Keith Miller
Comment 2 2022-01-21 09:23:32 PST
I don't think it matters if it returns `true` or `false`. That return boolean is to flag whether an Out of Bounds memory exception should be thrown but any access triggering one of those asserts isn't out of bounds. Do you think that an OoB exception is better than a no-op if we have a bug in our implementation? It seems to me a no-op is easier to work around for a dev?
Note You need to log in before you can comment on or make changes to this bug.