Re: Using alloca in function parameters buggy or works ???

[espie at quatramaran dot ens dot fr (Marc Espie)]

In article <4149BFCE.3010609@gnat.com> you write:
>Well I am not so sure this is the right attitude. It may be more valuable
>to sign up for the "let's make sure we don't use too many resources"
>school of programming. I personally think that problems of excessive
>memory use are often better addressed by drastically reducing memory
>use in the first place.


Personally, I tend to think `let make it clear what is temporary and
what is more permanent storage'. This is not always clear, but knowing
that storage is local to a function and should not escape in the wild,
or, for instance, having a very clear return path for a function that
does allocate and return memory does help quite a bit.

In my mind, smart gc algorithms take over when this is unclear.

But come on, local algorithms can be written in a clear way... and
alloca stuff won't help all that much.  If it's alloca, then it's
totally local storage, and then temps are just as clear.

Also, this helps in case of code audits: when hunting for memory leaks,
knowing the state of a function wrt to memory allocation does help quite
a lot.

Kaveh's message prompted me in having a closer look at gcc 2.9's use of
concat. Simply put, it's a mess. It's not at all clear which ones are
local and should go. And it's not at all clear what the life extent of
non-local ones are, and if memory can be easily regained, since one has
to find the uses of the function that uses concat, and not just the uses
of concat itself.