Re: (patch) strdupa for GLib - 2nd try

[Manish Singh <yosh gimp org>]

> > The following patch adds strdupa support to GLib - duplicate a string on
> > the stack.  As Ulrich Drepper noted yesterday, alloca is many, many times
> > faster than g_malloc/g_free.
> > 
> > I will commit unless there are objections.
> 
> Hmm, do you necessarily need to include alloca.h - the right way on many
> systems to get alloca() prototype is by including stdlib.h (as per 'man
> alloca' on Linux & Solaris). IRIX 6.4 seems to need alloca.h, so there
> doesn't seem to be any rule of thumb...?

alloca() declaration stuff is a bit of a mess really, which is why autoconf
provides AC_FUNC_ALLOCA. The info documentation is quite lucid on the
topic, so I suggest reading up on that (it even has provisions for using
an alloca.c if it's not found at all on the system.

Now regarding headers, I think we should strive to keep glib.h from
polluting the namespace much more than it does now, since #including
some headers can produce breakage (which is why we pull the defs from
pthread.h and sys/poll.h instead of #including them directly). Now I
dunno how to do this with with alloca, or even if we can, any ideas? :)

-Yosh