Skip to content

wasm-edit -- Valid edits can throw with default decode options. #405

@TimHambourger

Description

@TimHambourger

Description

Because of the assertNotIdentifier calls in wasm-gen/lib/encoder/index.js, editing, say, a module export name can throw with the default decode options.

Steps to repro

Start with input WASM corresponding to the WAT

(module
  (func $add (param $lhs i32) (param $rhs i32) (result i32)
    get_local $lhs
    get_local $rhs
    i32.add)
  (export "add" (func $add))
)

(from MDN's examples).

Then edit the export name like

import { edit } from '@webassemblyjs/wasm-edit';

const bin; // ArrayBuffer containing .wasm contents

edit(bin, {
    ModuleExport(path) {
        path.node.name += '!!';
    }
});

This throws with "Unsupported node Identifier" due to the assertion at

function encodeModuleExport(n) {
  var out = [];
  assertNotIdentifierNode(n.descr.id);
  // etc.
}

If you instead decode with ignoreCustomNameSection: true then the edit succeeds:

import { decode } from '@webassemblyjs/wasm-parser';
import { editWithAST } from '@webassemblyjs/wasm-edit';

const bin; // ArrayBuffer containing .wasm contents

const ast = decode(bin, {
    ignoreCustomNameSection: true
});

editWithAST(ast, bin, {
    ModuleExport(path) {
        path.node.name += '!!';
    }
});

At the relevant assertion, n.node.descr now has type 'NumberLiteral' instead of 'Identifier'.

Expected behavior

That valid edits succeed with default decode options. The current behavior feels restrictive.

Other Cases?

This behavior with export names seems to repro reliably across input .wasm files. I also found a possible repro with import names, but that one only affected some of the files I tested and might be due to a bug with decode. I'll file that separately.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions