On Tue, 10 May 2011 18:33:42 +0100, Richard Shann wrote
On Sun, 2011-05-08 at 11:39 +0200, R. Mattes wrote:
BTW, my code example is longer than it needs to be, there's no
need
to establish a dynamic context at all - I was fooled by the
original
code. No idea why there's scm_dynwind_... at all. No need for it.
Jeremiah - Ralf is confirming my suspicions here - I think we should
simply be calling g_free() on the strings that we have created on
the
heap.
Yes. Guile won't free any memory you allocate in C.
I am not sure what scm_dynwind_... is for, if it is doing anything
it is only saving us the effort of writing those g_free() calls
before returning.
It won't. Dynamic (un)winding has a different purpose. In a situation
like the following:
a_thing = alloc_new_thing();
scm_eval_string(); <------- [1]
free_thing(a_thing); <----- [2]
The call in [1] transfers control to scheme. Now, in Scheme function
calls might never return since it's always possible to do non-local
exits
(for example by call-with-current-continuation). So it's not
guaranteed
that [2] is ever reached. This might leak memory.
Now scm_dynwind_ sets up an unwinding context. This is only a setup,
you still
need to register cleanup functions with that context. Now whenever
scheme
leaves this dynamic context by means of a non-local exit these
cleanup
function are called (Richard, since you seem to have some Lisp
bakground:
this is the C equivalent of Common Lisp's unwind-protect).
So, setting up a dynamic context without registering some sort f
cleanup
with it ( scm_dynwind_unwind_handler(a_thing) in my example) simply
does
nothing (Hint: Guile has a very fine manual - Section 'Dynamic
Winds').