🚀 go-pugleaf

In article <4koe4u$8sl@solutions.solon.com>,
Lars Wirzenius <wirzeniu@cc.helsinki.fi> wrote:
>dtrg@st-andrews.ac.uk (David Thomas Richard Given):
>> I think I mentioned using alloca() on this newsgroup before, and received 
>> quite a lot of mail telling me that it was nonstandard, nonportable, and 
>> that use of it was generally heinous. :)
>> 
>> The problem is, it's so useful. There's a lot of cases when I write 
>> programs when I allocate a variable-sized buffer at the beginning of a 
>
>> function. If I use malloc(), I have to remember to free it at the end. 
>
>Instead of this:

[example snipped]

>Do this:

[replacement example changing alloca() to malloc() and inserting free()
also snipped]

Your example is too simple; that's an obvious conversion.
Much more difficult is where alloca() has been used in a loop, to
(for example) build a linked list (or worse) on the stack, and
"return" has been used to free all the spaghetti.

And, in answer to the original poster's question, yes, implementations
without alloca() do exist; I had to port such spaghetti to one
(some version of Venix) and it was a real mess.

>> My question is, is there a legal alloca() I can use anywhere? 
>
>I don't think so.  See the FAQ, question 7.32.

Agreed.

alloca() is a bit like the "struct hack" which is where you'd
like to use:
	struct hack { int real_size; char buffer[0]; } hack;
for variable structs.  (Usually discussed with "[1]" since "[0]"
is illegal there, but it could therefore be implemented with
[0] to mean "unknown size", and some compilers do this as an
extension.)  The problem is, hack is no longer a full-fledged
struct (assigning one to another, or passing one to another
function, can't work), and in a sense is a new type.

alloca() is also similarly situated.  In "simple" cases, you
can use it and it seems like a function, but you can't do
everything with it that you can do with other functions; it's not
a full-fledged function.  I forget what breaks it exactly, but passing
a pointer to it certainly makes implementation a mess for some
architectures.

I wouldn't mind seeing either alloca() or the "struct hack" in a
future standard for the language, provided that the compiler
was required to issue a diagnostic for attempts to use them in
contexts where they couldn't (or might not) work.  But I don't
see it happening, because they are sort of special cases.
They both have their uses, though, and "prior art" exists.

Cheers,
Stan.
--
Stan Ryckman  (stanr@tiac.net)