Re: alloca (fwd)

[Elliot Lee <sopwith redhat com>]

On Wed, 20 Jan 1999, Jeff Garzik wrote:

> > What do you think about this as a rough implementation of alloca for
> > glib 1.3:
> > 
> > #if G_HAVE_ALLOCA
> > #  define g_malloc_a alloca
> > #  define g_free_a(ptr) G_STMT_START G_STMT_END
> > #else
> > #  define g_malloc_a g_malloc
> > #  define g_free_a g_free
> > #endif
> > 
> > By simply requiring the programmer to free memory like they would
> > without alloca, you provide a drop-in replacement without requiring some
> > godawful alloca replacement implementation.

"simply requiring", my goodness. Please, don't put this in. alloca doesn't
work this way in real life.

Tim's suggestion of putting the gc function into the main loop seemed
fairly sane to me - it allows alloca() to behave exactly the same way on
all platforms. Compatibility stuff works best if you can make it work the
way it is "supposed" to work on all platforms, and the GC-in-main-loop
approach does this.

The other macros (strdup_a, strconcat_a, etc.) are also non-intuitive to
use - they don't (and, for glib's purposes, can't) follow the pattern of
their malloc-using cousins.

Stack allocation needs to be done directly by the programmer, because it
is a different beast than malloc. You're trying to generalize something
that has enough differences from regular malloc to cause some real
problems.

Just guarantee the develoepr a working alloca(), hook GC in the main loop
if using a fake alloca, and leave it at that.
-- Elliot
"In film you will find four basic story lines. Man versus man, man
 versus nature, nature versus nature, and dog versus vampire."
    - Steven Spielberg