Feature request: an "unmanaged" string view type

[vrotaru]

Or more generally allow the user to create views types where the memory which is allocated on OCaml side is GC-ed, but the one which is passed to the C is not freed when it is not longer reachable.

Motivating example:

I'm trying to pass an OCaml callback to C which returns a string. After that the C code "takes ownership" of the returned string
and frees it after use.
Then when the char ptr holding a reference to string on OCaml side is garbage collected this function

ocaml-ctypes/src/ctypes/managed_buffer_stubs.c

Line 19 in 96e1ac3

static void finalize_free(value v)

is called and it tries to free it again.

The result of this double-free is that the program crashes.

So, if that is possible, I want an unmaged_string where the finalizer for that custom block is null or does nothing.

[yallop]

I think it's better to avoid string (and other views that let OCaml handle memory management) in these situations. If you want to allocate memory that some C code will later pass to free then one approach is to bind malloc and allocate the memory that way.

[vrotaru]

A bit of context to that feature request/wish. I was trying to create on OCaml side a class wrapping gtk_cclosure_expression and passing to the C constructor a string -> string OCaml function. (ctypes makes it easy)

What happens is that a GLIB gvalue structure is stack-allocated, and a pointer to it passed to some other C function, until ultimately the OCaml function is called and the returned char * pointer in stored in the gvalue structure.

When the stack-allocated gvalue is about to exit form scope "clear" is called on it, and it is than the first call to free happens.
And after that the second call to free happens during an OCaml GC.

Hope this helps. This is no longer a concern for me, so there is no urgency. Do the right thing, whatever you consider it to be.