Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No API to manipulate table entries #5

Closed
roman-kashitsyn opened this issue May 1, 2020 · 3 comments · Fixed by #12
Closed

No API to manipulate table entries #5

roman-kashitsyn opened this issue May 1, 2020 · 3 comments · Fixed by #12

Comments

@roman-kashitsyn
Copy link

The table API looks pretty much as a placeholder now, one can't do anything useful with it:

type Table
func (t *Table) AsExtern() *Extern
func (t *Table) Size() uint32
func (t *Table) Type() *TableType

The Rust API is actually useful. Examples of missing methods:

pub fn get(&self, index: u32) -> Option<Val>

pub fn set(&self, index: u32, val: Val) -> Result<()>

pub fn grow(&self, delta: u32, init: Val) -> Result<u32>

pub fn copy(
    dst_table: &Table,
    dst_index: u32,
    src_table: &Table,
    src_index: u32,
    len: u32
) -> Result<()>
alexcrichton added a commit to alexcrichton/wasmtime that referenced this issue May 4, 2020
This commit adds a suite of `wasmtime_funcref_table_*` APIs which mirror
the standard APIs but have a few differences:

* More errors are returned. For example error messages are communicated
  through `wasmtime_error_t` and out-of-bounds vs load of null can be
  differentiated in the `get` API.

* APIs take `wasm_func_t` instead of `wasm_ref_t`. Given the recent
  decision to remove subtyping from the anyref proposal it's not clear
  how the C API for tables will be affected, so for now these APIs are
  all specialized to only funcref tables.

* Growth now allows access to the previous size of the table, if
  desired, which mirrors the `table.grow` instruction.

This was originally motivated by bytecodealliance/wasmtime-go#5 where
the current APIs we have for working with tables don't quite work. We
don't have a great way to take an anyref constructed from a `Func` and
get the `Func` back out, so for now this sidesteps those concerns while
we sort out the anyref story.

It's intended that once the anyref story has settled and the official C
API has updated we'll likely delete these wasmtime-specific APIs or
implement them as trivial wrappers around the official ones.
@alexcrichton
Copy link
Member

Thanks for the report! This isn't actually currently possible with the C API so I've added some extensions to do this, and once that lands I'll bind them here.

sunfishcode pushed a commit to bytecodealliance/wasmtime that referenced this issue May 13, 2020
This commit adds a suite of `wasmtime_funcref_table_*` APIs which mirror
the standard APIs but have a few differences:

* More errors are returned. For example error messages are communicated
  through `wasmtime_error_t` and out-of-bounds vs load of null can be
  differentiated in the `get` API.

* APIs take `wasm_func_t` instead of `wasm_ref_t`. Given the recent
  decision to remove subtyping from the anyref proposal it's not clear
  how the C API for tables will be affected, so for now these APIs are
  all specialized to only funcref tables.

* Growth now allows access to the previous size of the table, if
  desired, which mirrors the `table.grow` instruction.

This was originally motivated by bytecodealliance/wasmtime-go#5 where
the current APIs we have for working with tables don't quite work. We
don't have a great way to take an anyref constructed from a `Func` and
get the `Func` back out, so for now this sidesteps those concerns while
we sort out the anyref story.

It's intended that once the anyref story has settled and the official C
API has updated we'll likely delete these wasmtime-specific APIs or
implement them as trivial wrappers around the official ones.
alexcrichton added a commit that referenced this issue May 14, 2020
alexcrichton added a commit that referenced this issue May 14, 2020
@avidal
Copy link
Contributor

avidal commented May 15, 2020

Can you tag a v0.16.2 release for tables?

@alexcrichton
Copy link
Member

Sure thing, done!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants