Bug 234967 – JSC::Wasm::setWasmTableElement() falls through ASSERT_NOT_REACHED()

• Component: WebAssembly
• Status: NEW

[David Kilzer (:ddkilzer)]

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.

[Radar WebKit Bug Importer]

<rdar://problem/87260620>

[Keith Miller]

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?