-
Notifications
You must be signed in to change notification settings - Fork 7
Description
I experimented with the new (in 1.1.0) string parameters. I haven't yet been able to actually run the generated code but from looking at it it seems that the memory deallocation should work that way. I also like the freeAfterCall option, so that the user can decide how to deal with the memory. But I haven't seen any similar feature for the string return values. The library code cannot deallocate the memory of the returned string after executing the return statement of a function. This has to be done on the caller side. As far as I understand it the generated code could deal with that in two ways. Either it could make a copy of the string returned from the wasm function, then deallocate the memory of the returned string and then return the copy to the caller or it could generate a function which takes a lambda block where the user can decide what to do with the string and then it is deallocated automatically after this block was executed. The later would avoid having to make a copy of the string and would be similar how native C interop handles memory. (https://kotlinlang.org/api/core/kotlin-stdlib/kotlinx.cinterop/mem-scoped.html) At the moment it does not even seem to be possible to free that memory manually because the generated code hides the pointer to that memory inside of it.