denemo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Denemo-devel] Midi shortcuts


From: R. Mattes
Subject: Re: [Denemo-devel] Midi shortcuts
Date: Tue, 10 May 2011 23:39:08 +0200

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'). 

> Even more surprising, I have looked into what is 
> happening with the scm_take_from_locale_string/n calls. In principle 
> guile should be freeing the passed string when it is finished with 
> it. 

What makes ou belive this? The function signature in my header files is:
 SCM_API SCM scm_from_locale_string (const char *str);
Why would you expext a 'const char*' block to be freed?


HTH RalfD

--
R. Mattes -
Hochschule fuer Musik Freiburg
address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]