Calling __wbindgen_malloc

[ted-gould]

Summary

When trying to use a guest module I want to allocate memory in a way that it can manage. As far as I can tell my guest (which is written in Rust using bindgen) exports a symbol __wbindgen_malloc that could be used to do this. This is how the bindgen JS bindings work. But everytime I call that function it returns 0 for a pointer. No matter how many times (i.e. it could in theory for the first call, but the second should be after that memory area).

Additional details

Mostly trying to implement a function that takes a string as a parameter and returns a string. I have the returning string working well, but the input is not. It seems like I shouldn't just "allocate memory and hope" it doesn't conflict with anything. But I'm not sure how to tie into the guest's memory allocation machinery.

Thanks.

[ted-gould]

Here is a link to the code I'm doing, just to provide some more context: https://gitlab.com/ted.gould/inkscape/-/blob/wasmer/src/extension/implementation/wasmer.cpp#L146

Also, you might need to reference the wrapper I have on the C API for C++: https://gitlab.com/ted.gould/inkscape/-/blob/wasmer/src/extension/implementation/wasmer-wrap.h

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Hywan]

Hello,

wasm-bindgen is designed to work on a JavaScript host. It's very likely that things can break or can not easily be made compatible with another host.

Why using wasm-bindgen for a non-Web usage?

[ted-gould]

🤷 No one told me not to? 😄

I guess I don't know what should be used for a non-web host then. It seems like that largely all the documentation pointed in that direction. Do you know of docs that explain how to setup a non-web host, tool, etc? I guess I'm confused on how things are supposed to work in the non-web cases.

[Hywan]

There is a proposal, called Interface Types, but it is still at phase 1 (understand, super unstable). For the moment, you need to deal with your memory by-hand and manipulate integers and floats only.
What are you trying to do :-)?

[ted-gould]

So what I was playing with is the idea that an Inkscape Extension could be build with WASM. This would have a few benefits including being single file and allow for sandboxed execution. Also cross-platform.

To over-simplify a bunch, an Inkscape Extension takes in an SVG (XML string) and returns SVG (XML string) that is modified in some way. So I need string support on both sides, which (again to oversimplify) means malloc.

Is that something that is reasonable to do today? Or is it wiser to wait a bit until things flesh out?

[Hywan]

It is absolutely reasonable. You can write export 2 functions:

• allocate,
• deallocate.

And then one function to process the SVG file.

Something like this (example with a Rust program that we will compile to Wasm):

use std::ffi::{CStr, CString};
use std::mem;
use std::os::raw::{c_char, c_void};

#[no_mangle]
pub extern fn allocate(size: usize) -> *mut c_void {
    let mut buffer = Vec::with_capacity(size); // naive way to allocate something
    let pointer = buffer.as_mut_ptr();
    mem::forget(buffer);

    pointer as *mut c_void
}

#[no_mangle]
pub extern fn deallocate(pointer: *mut c_void, capacity: usize) {
    unsafe {
        let _ = Vec::from_raw_parts(pointer, 0, capacity);
    }
}

// # Safety
//
// The string `svg` must be nul-terminated. Otherwise, let's update the code to support a length.
#[no_mangle]
pub extern fn process_svg(svg: *mut c_char) -> *mut c_char {
    let svg = unsafe { CStr::from_ptr(svg).to_bytes().to_vec() };

    // … do something and return a string
}

Then compile it to Wasm with:

$ cargo --target wasm32-unknown-unknow …

and you're good :-). Your resulting .wasm file will export 3 functions: allocate, deallocate and process_svg.