Stability of wasm exports for allocation

[codefromthecrypt]

There are wasm exports like "malloc" and "free" which make it seem like you can allocate outside code compiled by TinyGo and not collide with memory managed by code compiled by TinyGo. This seems like a dangerous practice, but also intentionally not using it is extremely complicated (ex tracking references and re-exporting your own functions as described in #2787)

It would help to get an answer on these special exports, what they are expected to do and if they are stable. If they are stable, simpler instructions can be made like https://wasmedge.org/book/en/embed/go/memory.html#pass-bytes-to-tinygo-functions

If they aren't stable, then solving #2787 will be more complicated.

By stable, I mean the signatures and exports not disappearing on future releases, and the behavior understood. Ex if you call malloc, you won't get collissions by code managed in Go, and that remains the case until "free" is called. Moreover, that you can pass ownership of memory to an external function and they can call "free" to clear it.

I still think #2787 will be nuanced after this, but a decision here will impact how complex that will be.

[aykevl]

Yeah we should document it. The way WebAssembly works is certainly not well enough documented.

But to answer your question:

It would help to get an answer on these special exports, what they are expected to do and if they are stable.

To be honest, they were exported by accident. They are there so that wasm-libc works (it needs malloc), but by accident they also got exported out of the module. So I wouldn't count on them to remain available.

[codefromthecrypt]

I will close this, though would warn against removing these exports as they are all over the ecosystem in many runtime examples. Provided they don't hurt I wouldn't eagerly remove them!