Re: RFC: glocal - automatically freeing memory when it goes out of scope

[Mikkel Kamstrup Erlandsen <mikkel kamstrup canonical com>]

On 05/29/2012 10:21 PM, Ben Pfaff wrote:
> Mikkel Kamstrup Erlandsen<mikkel kamstrup canonical com>  writes:
>
> > On 05/29/2012 07:23 PM, Ben Pfaff wrote:
> > > Mikkel Kamstrup Erlandsen<mikkel kamstrup canonical com>   writes:
> > >
> > > > I have been looking at gcc's "cleanup" attribute[1] that allows one to
> > > > specify a callback that will be invoked when a variable goes out of
> > > > scope. This allows one to play with automatically freeing resources.
> > >
> > > Is it possible to combine use of this GCC-specific attribute with
> > > the concept in Doug Gwyn's "mostly-portable" alloca
> > > implementation, so that you would end up with something that
> > > works pretty much everywhere (but is more efficient with GCC)?
> > >
> > > Here's one copy of the Doug Gwyn alloca that just happened to be
> > > on the top of the results of my web search:
> > >           ftp://ftp.dante.de/tex-archive/fonts/utilities/ps2mf/alloca.c
> >
> > There is already g_alloca() and g_newa() for allocating on the stack.
>
> I'm not suggesting an implementation of an alloca-like function
> based on these ideas; as you say, glib already has alloca-like
> functions.
>
> I'm suggesting that one could use the idea behind the Doug Gwyn
> portable alloca to implement something like, or at least related
> to, the GCC "cleanup" attribute even when GCC is not the compiler
> in use.  (However, the attribute syntax wouldn't work, and the
> interface would otherwise need to be different.)

Sorry, I misunderstood you then :-) I am afraid the answer is no.

alloca() does not provide a callback when cleaning up, and we need that 
for anything that needs a teradown function - which is basically 
everything that is not a string...

Also this portable alloca() mentions in the docs that memory is not 
guaranteed to be freed when you leave the scope, but mayb happen higher 
up in the stack - and there even should be a mainloop driving "garbage 
collection" with alloca(0) as well. This means that the automagic lock 
management I added wouldn't work fx.

Cheers,
Mikkel