The `returns_len` argument type of `wasmer_export_func_returns_params`
must be `uint32_t` to match the `wasmer_export_func_returns_arity` results,
so that casts are not required.
The `params_len` argument type of `wasmer_export_func_params_arity`
must be `uint32_t` to match the `wasmer_export_func_*_arity` results,
so that casts are not required.
The `wasmer_export_func_params_arity` and
`wasmer_export_func_returns_arity` functions store the arity in a
`uint32_t`. The `wasmer_instance_call` expects `c_int`. There is a
type mismatch here. It's not annoying in C or C++, but in some other
languages that have bindings to C/C++, it can imply useless casting.
This patch changes `wasmer_instance_call` to expect `uint32_t` for
`params_len` and `results_len` to match the
`wasmer_export_func_*_arity` functions.
It's safer to check the buffer size is large enough to hold the error
message before creating the slice from raw parts.
Also, this patch remove the need for `last_error`, simplifying the
code a little bit. The `length` variable is casted to `usize` once.
Memory clone function wasn't able to write to new reserved memory object.
Changed so allocating Memory objects with protection flag allocates commited memory.
414: Exception logging (win32): Handle error codes correctly, add some more strings r=syrusakbary a=hrydgard
Ran into a situation with an unknown exception from Cranelift (will probably report that one separately). Turns out the signum was "1" though which does not seem to correspond to any of the Windows error codes, except possibly STATUS_GUARD_PAGE which is 0x80000001, but only if we lost the top bit somewhere.
On Windows, exceptions seemed to be trapped by callProtected, which is implemented here: cade9a666f/lib/win-exception-handler/exception_handling/exception_handling.c . It did not seem to correctly store and retrieve the exception code, instead always returning 1: ```longjmp(jmpBuf, 1);```
So I fixed it. And now the log output looks like this:
```
unhandled trap at 1560d5e7bab - code #c0000005: segmentation violation
```
Co-authored-by: Henrik Rydgård <henrik.rydgard@embark-studios.com>
Co-authored-by: Syrus Akbary <me@syrusakbary.com>
Co-authored-by: Mackenzie Clark <mackenzie.a.z.c@gmail.com>
