Hi Megane,
Like Evan says, the libgit2 project doesn't keep your pointers around so
that should be safe. But thanks for pointing that out, errors caused by
these things are very hard to track down.
I'd actually never thought about a off-gc memory heap before. That is a
very interesting idea! I'm
I think we can probably just use blobs and locatives to keep things
simple, without needing to involve finalizers or similar tricks. This
library is pretty good about leaving memory management up to the client,
and they provide an object for indirection (the git_buf) when that's not
possible.
Kristian Lein-Mathisen writes:
> Hi,
>
> Indeed. We could malloc and set-finalizer! and that should work and be
> safe. However, as far as I understand, this approach has some disadvantages:
>
> - malloc is relatively slow compared to chicken's internal allocation (eg
> make-string) that uses
Hi,
Indeed. We could malloc and set-finalizer! and that should work and be
safe. However, as far as I understand, this approach has some disadvantages:
- malloc is relatively slow compared to chicken's internal allocation (eg
make-string) that uses the stack
- there is a practical limit on
