Re: glib: alloca brain damages

[Elliot Lee <sopwith redhat com>]

On Mon, 4 Jan 1999, Tim Janik wrote:

> On Mon, 4 Jan 1999, Elliot Lee wrote:
> 
> > 1.
> > 
> > #  define g_new0_a(type, count)	  \
> >       ((type *) memset (alloca ((unsigned) sizeof (type) * (count)), 0, \
> >       			((unsigned) sizeof (type) * (count))))
> > 
> > Very bad - this is allocating a place on the stack while the compiler is
> > trying to set up the stack for the function call. It should be something
> > like

> > #  define g_new0_a(type, count)	\
> > 	G_STMT_STRT { \
> > 		char *newblock;
> > 		newblock = alloca(sizeof(type) * count);
> > 		memset(newblock, 0, sizeof(type) * count);
> > 	} G_STMT_END
> > 
> > 
> > The problem is that G_STMT_STRT casts the block to (void), and ANSI C does
> > not permit ({expr;}), so there's really no way to do it portably.
> > 
> > 2. There's the whole problem of doing all these macros at all. On some
> > arches/OS's, alloca() won't work inside conditionals, or inside {} blocks.
> 
> hm, sopwith, can you eventually provide concrete reports about such
> behaviour? we shouldn't provide alloca using macros at all if that's affecting
> any system that glib currently runs on.

OK, #2 was a misunderstanding on my part, but #1 most definitely is a
problem. RTH says any machine that does push/pop (m68k, x86) will have
problems with that.

So, either the signature of g_new0_a needs to change, or we need to use
the ({ ... }) construct (which is a gcc extension).

-- 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