On 2024.08.07 23:55, brian m. carlson wrote: > On 2024-08-07 at 23:05:00, Josh Steadmon wrote: > > Yeah, needing to free() is the only thing we striclty need from libc > > right now. Please correct me if I'm wrong, but IIUC then any memory that > > is allocated on the C side and then passed to Rust needs one of: > > 1) freed by libc::free() on the Rust side, > > 2) passed back to the C side to be freed there, or > > 3) leaked > > > > Am I correct in assuming that your opinion is that writing additional > > *_free() functions on the C side is worth it to avoid libc? If so, then > > I'm fine with including that in V2. > > I think if we're going to be writing a general purpose API for > libification, we probably should provide free functions. Normally, that > will be a call to free(3) [snip] So in this case, does that mean we'd replace our call to `libc::free()` with just `free()`, and then add a declaration for `free` in our `extern "C"` section of cgit-sys? It seems to work on my machine, but is that actually the more portable option compared to using libc::free? Or have I misunderstood something?
