Thread (138 messages) 138 messages, 11 authors, 2025-01-30

Re: [RFC PATCH 3/6] contrib/cgit-rs: introduce Rust wrapper for libgit.a

flat view

From: Josh Steadmon <hidden>
Date: 2024-08-08 18:22:21

On 2024.08.07 23:55, brian m. carlson wrote:
On 2024-08-07 at 23:05:00, Josh Steadmon wrote:
quoted
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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help