Closed mt-caret closed 1 year ago
@mt-caret looking into it, but in general, what you say is correct, the generated code should accept a pointer there, then read each value from an offset. Also, argn
shouldn't be an isize
, but an i32
(just re-checked the OCaml docs and it is an int
in C)
Aha, interesting, I hadn't considered that aspect. In that case (kind of pedantic, but...), do we want to use this type instead of an i32
? https://doc.rust-lang.org/std/os/raw/type.c_int.html
Just pushed to #53
Aha, interesting, I hadn't considered that aspect. In that case (kind of pedantic, but...), do we want to use this type instead of an
i32
? https://doc.rust-lang.org/std/os/raw/type.c_int.html
yes!
@mt-caret just published v0.9.2 with the fix. Thank you for the debugging work and report.
Thanks for the blazing-fast response!! :)
Hi,
The following function:
Gets expanded to:
If you were to write this out manually, the Rust compiler gives the following warning:
And in fact, when actually calling this function from bytecode in OCaml I observe panics like
thread '<unnamed>' panicked at 'expected 7 arguments, got 94909550696832'
.I believe we actually want to take a
*const ::ocaml_interop::RawOCaml
and convert it to a slice using::std::slice::from_raw_parts(argv, argn as usize)
.I hit this issue with my own macros which mirror the expansion behavior of
ocaml_export!
in ocaml-interop (but with some additional convenience modifications), and hit this issue which I was able to fix with the above change (commit here: https://github.com/mt-caret/polars-ocaml/pull/37/commits/337727bff33d3cede060155d35edfabc812864b0).