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 memory? Alexis -- 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.