Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support bindings for custom blocks #759

Open
mwlon opened this issue Jan 9, 2024 · 4 comments
Open

Support bindings for custom blocks #759

mwlon opened this issue Jan 9, 2024 · 4 comments

Comments

@mwlon
Copy link

mwlon commented Jan 9, 2024

As far as I can tell, there is no way in ctypes to return a custom block. I'd imagine this would work something like the following:

binding:

type t = custom_block
let t: t typ = custom_block_t
let foo = foreign "foo" (void @-> returning t)

generated C stub:

value <something>_foo() {
  value x = foo(); // foo is some function calling caml_alloc_custom or caml_alloc_custom_mem
  CAMLreturn(x);
}

Is this already implemented and just something I overlooked? If not, this seems like an important piece of functionality to add.

@NicolasT
Copy link

This would still require to have foos around which, somehow, return custom_block values, hence, some kind of OCaml-specific C stubs.

What if custom_block_t could (somehow) take the address of a custom_operations as an argument, so any regular C function taking or returning some value (to be extracted from/embedded in a custom_block in the generated stubs) could be used? (Note I didn't give this much thought, it may not be possible at all of course).

@mwlon
Copy link
Author

mwlon commented Mar 27, 2024

@NicolasT I think that approach might not work, since we also need to inform OCaml of size, used, and sometimes max, which might be dynamically determined upon each allocation. Custom blocks are definitely a power-user feature, so it seems reasonable and easier to me if we leave their usage to the user.

@NicolasT
Copy link

Right. For the use-case I had in mind, the wrapped value is always a pointer itself, so size is a known constant. used and max could be 0 and 1 since I can't know how the actual size of whatever is behind that pointer anyway :)

@mwlon
Copy link
Author

mwlon commented Mar 29, 2024

For that use case, could you just use a ptr void type? I think ctypes handles that out-of-the-box

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants