Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #66471

Re: lalloc() -- local stack allocation

Show all headers | View raw

> Does C define a type of lalloc() function for local / stack allocation?

No.

It sounds like you are talking about the GNU alloca() function.
I encountered it long before C11's optional run-time-dimensioned
arrays.

1.  You can trivially define alloca(x) to call malloc(x).  Ignore
the memory leaks, full speed ahead.  You really get no advantages
from this.

2.  alloca() is really intended to use the stack pointer (yes, we
know some implementations don't have one), and automatically free
allocated memory on return of the function in which it is invoked.
You lose a lot of the speed advantage if you insist that alloca()
return NULL on stack overflow.

It's supposed to work to allocate memory inside a loop, so you have
to keep track of how much memory was allocated, or save and restore
the stack pointer at function entry and exit.

It is pretty much impossible to implement an alloca() nontrivially
that works without compiler special treatment of the function.  (If
you are writing your own compiler, that's not a problem.  If you
are trying to retrofit it to an existing compiler, even if you have
source code, it may not be so easy.) A naive compiler will badly
mis-generate code for a function call where the arguments each call
alloca() and the number of arguments well exceeds the square of the
number of (temporary) registers used in passing arguments.  The
stack adjustments for alloca() and the stack adjustments for pushing
arguments on the stack for the call are going to get intermixed.

	sscanf(inputstring, 
		formatstring, 
		alloca(sizeof(int)),
		alloca(sizeof(int)),
		alloca(sizeof(int)),
		alloca(sizeof(int)),
		alloca(sizeof(int)),
...
		alloca(sizeof(double)),
		alloca(sizeof(double)),
		alloca(sizeof(double)),
		alloca(sizeof(double)),
...
		alloca(sizeof(long long)),
		alloca(sizeof(long long)),
		alloca(sizeof(long long)),
		alloca(sizeof(long long)),
		alloca(sizeof(long long)),
		alloca(sizeof(long long)),
		alloca(sizeof(long long)),
		alloca(sizeof(long long)),
		alloca(sizeof(long long))
	)

What is worse, when I presented such a problem, the pro-alloca
camp just said "Well, don't do that", but they couldn't describe the
circumstances I would have to avoid.  A compiler which allocated
and de-allocated variables local to an inner block of a function
at block entry and exit was a potential problem.  As I recall, the
best I could come up with was:

	alloca() may be used in a statement of the following form
	in the outermost block of a function (and it's not guaranteed
	to work anywhere else, like in a loop or block with local variables):
	<pointer variable> = alloca(integer constant expression or integer variable);
	double *z;
	size_t siz;
	int	num = 54;

	z = alloca(sizeof(double));	/* OK */
	z = alloca(num*sizeof(double))	/* *NOT OK* */

	siz = num*sizeof(double); z = alloca(siz);	/* OK */

on a system where (a) the compiler does not treat alloca() specially, or
(b) the compiler treats alloca() specially to perform stack adjustments, but
takes no care whatever to check that it is not in the middle of adjusting
the stack for other purposes (e.g. pushing arguments, or allocating
local variables for inner blocks).


I recall an attempt at an implementation on a 68000 processor.  It
ended up working reasonably for some software that we were trying
to get to work, but certainly not for all cases.  Because of the
way arguments were addressed (stack-pointer-relative, not
stack-frame-pointer relative), it had to allocate 48 bytes (a
compromise value.  Worst case it could need megabytes.) extra per
call to alloca().

A slight improvement on this would read and disassemble the code
of its caller (to figure out how many registers were being
saved/restored).  This sometimes malfunctioned if the compiler did
something clever that the writers of the code hadn't run into yet.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-12 02:23 -0700
  Re: lalloc() -- local stack allocation Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-07-12 11:48 +0200
    Re: lalloc() -- local stack allocation Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-07-12 11:48 +0200
  Re: lalloc() -- local stack allocation Philipp Klaus Krause <pkk@spth.de> - 2015-07-12 13:33 +0200
  Re: lalloc() -- local stack allocation Robert Wessel <robertwessel2@yahoo.com> - 2015-07-12 06:54 -0500
  Re: lalloc() -- local stack allocation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-12 06:17 -0700
    Re: lalloc() -- local stack allocation Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-07-12 16:47 +0200
      Re: lalloc() -- local stack allocation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-12 11:12 -0700
      Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-08 11:53 -0700
        Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 12:16 -0700
          Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-08 15:46 -0700
            Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 16:12 -0700
        Re: lalloc() -- local stack allocation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-08 20:32 +0100
        Re: lalloc() -- local stack allocation jadill33@gmail.com - 2015-09-08 13:25 -0700
  Re: lalloc() -- local stack allocation "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-07-12 10:17 -0700
  Re: lalloc() -- local stack allocation gordonb.zziiu@burditt.org (Gordon Burditt) - 2015-07-27 22:41 -0500
    Re: lalloc() -- local stack allocation Keith Thompson <kst-u@mib.org> - 2015-07-28 08:35 -0700

csiph-web