🚀 go-pugleaf

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:

	int foo(int bar) {
		int *temp;

		temp = alloca(bar*sizeof(int));
		if (temp == NULL)
			return -1;
		... do funny things with temp and bar and whatever ...
		return 0;
	}

Do this:

	static int aux_foo(int bar, int *temp) {
		... do funny things with temp and bar and whatever ...
	}
	int foo(int bar) {
		int *temp;
		int ret;

		temp = malloc(bar*sizeof(int));
		if (temp == NULL)
			return -1;
		ret = aux_foo(bar, temp);
		free(temp);
		return ret;
	}

> My question is, is there a legal alloca() I can use anywhere? 

I don't think so.  See the FAQ, question 7.32.

> I'd really like to be able to use this function. Can I?

How portable do you wish to be?

-- 
Lars Wirzenius <liw@iki.fi> <wirzeniu@kruuna.helsinki.fi>
MIME and PGP mail welcome.  Key: finger @kruuna, or check keyservers.
Publib http://www.iki.fi/liw/publib/

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)

In article <4kr7b2$kcb@solutions.solon.com>,
stanr@tiac.net (Stan Ryckman) wrote:
>
>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.

Yes, quite.

If you want to see how hard it is to define semantics for alloca that
are tight enough to allow scope checking and flexible enough to allow
the creation of linked lists, look at the Algol 68 scoping rules.  It
is a foul problem, which is why alloca is not always provided.

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

Actually, there are far more mainstream systems without alloca, and
even HP-UX did not have it until recently.  Your point stands :-)


Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679

In article <4koe4u$8sl@solutions.solon.com>,
wirzeniu@cc.helsinki.fi (Lars Wirzenius) writes:

|> 		int *temp;
|> 
|> 		temp = alloca(bar*sizeof(int));
|> 		if (temp == NULL)
|> 			return -1;

I have never seen a man page indicating that alloca can fail in the same
way as malloc.  I expect a SIGSEGV signal to be posted when stack extension
is no longer possible.  (I think this is a feature, since there is usually not
much you can do except terminate when memory runs out, anyhow.)

Konrad Schwarz

In article <4kr7b2$kcb@solutions.solon.com>, stanr@tiac.net (Stan Ryckman) writes:

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

It's unwise to call alloca when evaluating actual arguments of a function call,
since this will put the buffer smack in the middle of the argument passing
area on the stack.   (If you're sure that your target compilers don't
pass arguments in registers (very rare), you might be able to use this to pass a
run-time variable number of arguments.)

Konrad Schwarz

In article <4l1h2l$pns@solutions.solon.com>, schwarz@mips.complang.tuwien.ac.at (Konrad Schwarz) writes:
|> In article <4koe4u$8sl@solutions.solon.com>,
|> wirzeniu@cc.helsinki.fi (Lars Wirzenius) writes:
|> 
|> |> 		int *temp;
|> |> 
|> |> 		temp = alloca(bar*sizeof(int));
|> |> 		if (temp == NULL)
|> |> 			return -1;
|> 
|> I have never seen a man page indicating that alloca can fail in the same
|> way as malloc.  I expect a SIGSEGV signal to be posted when stack extension
|> is no longer possible.  (I think this is a feature, since there is usually not
|> much you can do except terminate when memory runs out, anyhow.)
On solaris the man page says about this:
     alloca() allocates size bytes of space in the stack frame of
     the  caller,  and  returns a pointer to the allocated block.
     This temporary space is automatically freed when the  caller
     returns.  Note: if the allocated block is beyond the current
     stack limit, the resulting behavior is undefined.

     alloca() is machine-, compiler-, and most  of  all,  system-
     dependent.  Its use is strongly discouraged.

As far as I know, a stack overflow generates a SIGILL.
On SGI si_code is set to ILL_BADSTK.
|> 
|> Konrad Schwarz

Joachim
-- 
---------------------------------------------------------------------
Joachim Huober                                Phone: +49 731 502-6241
UDINE-Project,            URZ, University of Ulm, 89081 Ulm , Germany
E-mail: joachim.huober@rz.uni-ulm.de 
---------------------------------------------------------------------

In <4kr7b2$kcb@solutions.solon.com> stanr@tiac.net (Stan Ryckman) writes:
>[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.

Another place where I've found alloca() very useful is to allocate
memory in a recursive descent parser for a simple calculator.
Instead of cluttering the code with error checks at every step and
having to free memory and pass error values back up the calling
chain, I just longjmp'd back to the top level parse() function
whenever one of the low level routines found an error.

So, just how non-portable and horrible is this?


Michael Gordon
--
Politicians are like nappies, both should be changed regularly
and for the same reason - graffito on a wall in Yeovil.

In article <4l1h2l$pns@solutions.solon.com>, schwarz@mips.complang.tuwien.ac.at (Konrad Schwarz) writes:
|> In article <4koe4u$8sl@solutions.solon.com>,
|> wirzeniu@cc.helsinki.fi (Lars Wirzenius) writes:
|> 
|> |> 		int *temp;
|> |> 
|> |> 		temp = alloca(bar*sizeof(int));
|> |> 		if (temp == NULL)
|> |> 			return -1;
|> 
|> I have never seen a man page indicating that alloca can fail in the same
|> way as malloc.  I expect a SIGSEGV signal to be posted when stack extension
|> is no longer possible.  (I think this is a feature, since there is usually not
|> much you can do except terminate when memory runs out, anyhow.)
|> 
|> Konrad Schwarz
The man pages of Linux and BSD4.3 indicate that alloca can fail returning
a NULL pointer. About SIGSEGV see my other posting.
-- 
---------------------------------------------------------------------
Joachim Huober                                Phone: +49 731 502-6241
UDINE-Project,            URZ, University of Ulm, 89081 Ulm , Germany
E-mail: joachim.huober@rz.uni-ulm.de 
---------------------------------------------------------------------

In article <4l5ckd$1t4@solutions.solon.com>, huober_j@spica.rz.uni-ulm.de (Joachim Huober) writes:

|> The man pages of Linux and BSD4.3 indicate that alloca can fail returning
|> a NULL pointer.

But in practice, with GCC's __builtin_alloca, it doesn't ever.
-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"

In article <4l33l8$7of@solutions.solon.com>, mfg@ee.edinburgh.ac.uk (Michael F Gordon) writes:

|> So, just how non-portable and horrible is [alloca]?

Mips has it, OSF/1 has it, AIX has it, HP-UX has it, PC's C have it (I'm pretty
sure), Venix (a PDP-11 Unix) doesn't have it, SUNs have it,
VAX has it (naturally).  Gcc might support it on some machines where the
native compiler doesn't.

If a compiler-writer forbids alloca, he can make the calling sequence quicker,
and not dedicate a register as a frame pointer.

Konrad Schwarz

In article <4l881b$762@solutions.solon.com>,
Konrad Schwarz <schwarz@hermi.complang.tuwien.ac.at> wrote:
>In article <4l33l8$7of@solutions.solon.com>, mfg@ee.edinburgh.ac.uk (Michael F Gordon) writes:
>
>|> So, just how non-portable and horrible is [alloca]?

[...]

>Venix (a PDP-11 Unix) doesn't have it,

Hmmm.  Is there more than one Venix?  The one I've used runs on
Intel machines.  Somebody, I think Novell (?) acquired them.

The Intel-based Venix doesn't have alloca() anyway.

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