I have some library that provides a function that produces a string:

   char* make_string(void);

…and the library expects that I will eventually free the returned memory
using a custom deallocator:

   void free_string(char*);

…can and should I use the _string C type with ffi/unsafe to call this
function? If I write the following:

   (define-mylib make_string (_fun -> _string))

…then when I call (make_string), how does Racket handle the memory of
that block of bytes? Presumably, the bytes returned by the call to
make_string must be copied into memory owned by Racket, but then what
happens to the original buffer? Does Racket call free on it, or is it
left dangling?

Dual to that question, what happens if I have a different API that gives
me a string, but it does NOT yield ownership to me?

   char* lease_string(void);

Once again, if I use the _string C type, will Racket copy the buffer
into a GC’d piece of memory managed by Racket and leave the original
string alone?

My assumption is that is what happens, which means _string will do the
right thing for the second function, but not for the first function,
which means I probably need to instruct Racket to call the free_string
deallocator on the buffer returned by make_string. However, if I use
_string, I no longer have a pointer to the original block of memory,
since Racket will copy it and return the Racket string. What’s the
correct way to instruct the FFI to call the free_string deallocator on
the returned buffer after it has finished copying it into GC-managed


You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to