Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #65394 > unrolled thread
| Started by | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| First post | 2015-07-12 02:23 -0700 |
| Last post | 2015-07-28 08:35 -0700 |
| Articles | 6 on this page of 86 — 20 participants |
Back to article view | Back to comp.lang.c
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 supercat@casperkitty.com - 2015-09-09 06:53 -0700
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-09 16:06 -0700
Re: lalloc() -- local stack allocation "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-09 16:17 -0700
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-09 16:26 -0700
Re: lalloc() -- local stack allocation "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-09 19:22 -0700
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-09 19:55 -0700
Re: lalloc() -- local stack allocation "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-09 20:46 -0700
Re: lalloc() -- local stack allocation "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-09 20:50 -0700
Re: lalloc() -- local stack allocation "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-11 23:59 -0700
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-12 06:22 -0700
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-09 21:10 -0700
Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-10 07:08 -0700
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-10 08:17 -0700
Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-10 08:54 -0700
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-10 09:19 -0700
Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-10 16:55 -0700
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-10 18:41 -0700
Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-11 09:04 -0700
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-11 10:17 -0700
Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-11 11:34 -0700
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-11 11:47 -0700
Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-11 13:44 -0700
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-11 17:52 -0700
Re: lalloc() -- local stack allocation "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-11 11:37 -0700
Re: lalloc() -- local stack allocation Richard Damon <Richard@Damon-Family.org> - 2015-09-10 08:24 -0400
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-10 05:55 -0700
RDC (Was: lalloc() -- local stack allocation) gazelle@shell.xmission.com (Kenny McCormack) - 2015-09-10 13:01 +0000
Re: lalloc() -- local stack allocation Richard Damon <Richard@Damon-Family.org> - 2015-09-11 00:29 -0400
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-11 05:37 -0700
Re: lalloc() -- local stack allocation Richard Damon <Richard@Damon-Family.org> - 2015-09-11 22:48 -0400
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-11 20:05 -0700
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-11 20:22 -0700
Re: lalloc() -- local stack allocation Melzzzzz <mel@zzzzz.com> - 2015-09-12 11:57 +0200
Re: lalloc() -- local stack allocation fir <profesor.fir@gmail.com> - 2015-09-12 04:34 -0700
Re: lalloc() -- local stack allocation fir <profesor.fir@gmail.com> - 2015-09-12 07:28 -0700
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-12 05:44 -0700
Re: lalloc() -- local stack allocation Ian Collins <ian-news@hotmail.com> - 2015-09-12 13:02 +1200
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-11 18:25 -0700
Re: lalloc() -- local stack allocation Ian Collins <ian-news@hotmail.com> - 2015-09-12 13:42 +1200
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-11 19:11 -0700
Re: lalloc() -- local stack allocation Melzzzzz <mel@zzzzz.com> - 2015-09-12 04:27 +0200
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-11 19:44 -0700
Re: lalloc() -- local stack allocation James Kuyper <jameskuyper@verizon.net> - 2015-09-11 23:01 -0400
Re: lalloc() -- local stack allocation Richard Heathfield <rjh@cpax.org.uk> - 2015-09-12 11:12 +0100
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-12 05:55 -0700
Re: lalloc() -- local stack allocation Richard Heathfield <rjh@cpax.org.uk> - 2015-09-12 14:16 +0100
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-12 06:24 -0700
Re: lalloc() -- local stack allocation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-12 10:57 -0700
Re: lalloc() -- local stack allocation fir <profesor.fir@gmail.com> - 2015-09-12 11:13 -0700
Re: lalloc() -- local stack allocation Gareth Owen <gwowen@gmail.com> - 2015-09-12 19:31 +0100
Re: lalloc() -- local stack allocation gazelle@shell.xmission.com (Kenny McCormack) - 2015-09-12 19:20 +0000
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-12 12:06 -0700
Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-12 14:24 -0700
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-12 19:22 -0700
Re: lalloc() -- local stack allocation Ian Collins <ian-news@hotmail.com> - 2015-09-12 14:54 +1200
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-11 20:18 -0700
Re: lalloc() -- local stack allocation Ian Collins <ian-news@hotmail.com> - 2015-09-12 16:20 +1200
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-12 05:43 -0700
Re: lalloc() -- local stack allocation "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-12 14:02 -0700
Re: lalloc() -- local stack allocation Melzzzzz <mel@zzzzz.com> - 2015-09-12 04:25 +0200
Re: lalloc() -- local stack allocation Bartc <bc@freeuk.com> - 2015-09-12 10:32 +0100
Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-09 16:23 -0700
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-09 16:38 -0700
Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-09 17:01 -0700
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-09 17:08 -0700
Re: lalloc() -- local stack allocation "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-09 17:37 -0700
Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-09 18:06 -0700
Re: lalloc() -- local stack allocation Bartc <bc@freeuk.com> - 2015-09-10 10:54 +0100
Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-09 16:24 -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
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-09-09 16:24 -0700 |
| Message-ID | <52630a27-3c25-4a77-8170-cc0ccc87538c@googlegroups.com> |
| In reply to | #70081 |
On Wednesday, September 9, 2015 at 6:07:15 PM UTC-5, Rick C. Hodgin wrote: > There are definitely workable solutions to allow allocation and > de-allocation. However, I still think the purpose of lalloc() would > be in its speed and no requirement of cleanup after use. > > // char* ptr = lalloc(20); > mov ptr,esp > sub esp,20 > > Two assembly instructions is all that's required to get the memory > allocated. Compare that to the overhead of a function call to > the stalloc() function, and then later a stfree() function, let > alone the processing involved in walking the local heap to see > where suitable blocks are. // stfree(ptr,20) mov esp,ptr add esp,20 A compiler could easily elide that immediately preceding a "mov esp,ebp" at the end of a function, though it should be noted that using that style of lalloc() would require that a compiler maintain a frame pointer if it has any local variables at stack-relative addresses, making lalloc() not quite so cheap as you suggest. > I agree we need a stalloc() and stfree() though. But, I think they > should be in addition to lalloc() which may need to be renamed > fastalloc() to convey its purpose. My complaint about a lalloc() that doesn't require a call to a "freeing" function is that not all platforms would be able to support it without making breaking changes to the ABI of things like setjmp/longjmp [with the stalloc and stfree as I've suggested, code which uses setjmp would need to do a stalloc(0) beforehand and a corresponding stfree() to avoid a memory leak if a longjmp() might be performed between an intermediate layer's stalloc() and stfree(), but code which doesn't need to support such semantics would not need to be modified.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-09-08 20:32 +0100 |
| Message-ID | <87fv2oogft.fsf@bsb.me.uk> |
| In reply to | #69952 |
supercat@casperkitty.com writes: > On Sunday, July 12, 2015 at 9:47:45 AM UTC-5, Johannes Bauer wrote: >> Which completely defies the purpose of using the system stack. Because >> there you don't have to free because free is implicit at the end of a >> function scope when the stackframe is cleared. > > A well-designed stack-allocate mechanism would have included a stack-free > function and required that code must use it to free objects in the reverse > order of allocation. Such requirements would have meant that every platform > that can run a reasonable dialect of C could support code using such > functions merely by chaining them to "malloc" and "free", but platforms which > can benefit from distinguishing between temporary and persistent objects > could make use of that knowledge. Even platforms would require that such > objects be allocated on the heap rather than the CPU stack may be able to > benefit from having separate functions for temporary allocations (e.g. by > maintaining a pre-allocated area for such allocations which is separate from > the main heap). > > The lack of a "free" function is bad in a number of ways: > > 1. It's incompatible with a pattern of "read size, allocate array, read and > process data, release array, read next size, etc." since memory that gets > stack-allocated within a method can't be freed. > > 2. On many platforms it makes it impossible to use a compatibility library > to allow code which is written to use alloca() to be run on a platforms > which doesn't include explicit support for it. > > 3. Unless a compiler adds some rather sophisticated alloca-related support, > it precludes the possibility of alloca() using a heap allocation rather > than a stack allocation in cases where stack memory is scarce. > > Having a function which allocates memory take care of releasing it isn't > hard, and while I could see semantic benefit to having a compiler squawk if > stack-allocate/stack-free calls aren't balanced, I don't see any upside to > the implicit freeing of alloca() memory which are even remotely close to > outweighing the drawbacks. I'm not good at assessing advantages and drawbacks, but you can always make yourself use such a language (in fact I have done so, knowing that alloca is fast on some target systems and simply absent in others). I.e. you write salloc and sfree which are either malloc and free or are alloca and an empty stub. It's not the same as having mandated features of course, but I suspect its the kind of thing that is considered by standards committees. (And if I understand the intent, you don't get number 3 as that's on the implementation side.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | jadill33@gmail.com |
|---|---|
| Date | 2015-09-08 13:25 -0700 |
| Message-ID | <d9a9d392-22db-4f93-bf65-9e219bec9249@googlegroups.com> |
| In reply to | #69952 |
On Tuesday, September 8, 2015 at 2:54:18 PM UTC-4, supe...@casperkitty.com wrote:
> On Sunday, July 12, 2015 at 9:47:45 AM UTC-5, Johannes Bauer wrote:
> > Which completely defies the purpose of using the system stack. Because
> > there you don't have to free because free is implicit at the end of a
> > function scope when the stackframe is cleared.
>
> A well-designed stack-allocate mechanism would have included a stack-free
> function and required that code must use it to free objects in the reverse
> order of allocation. Such requirements would have meant that every platform
> that can run a reasonable dialect of C could support code using such
> functions merely by chaining them to "malloc" and "free", but platforms which
> can benefit from distinguishing between temporary and persistent objects
> could make use of that knowledge. Even platforms would require that such
> objects be allocated on the heap rather than the CPU stack may be able to
> benefit from having separate functions for temporary allocations (e.g. by
> maintaining a pre-allocated area for such allocations which is separate from
> the main heap).
>
> The lack of a "free" function is bad in a number of ways:
>
> 1. It's incompatible with a pattern of "read size, allocate array, read and
> process data, release array, read next size, etc." since memory that gets
> stack-allocated within a method can't be freed.
>
> 2. On many platforms it makes it impossible to use a compatibility library
> to allow code which is written to use alloca() to be run on a platforms
> which doesn't include explicit support for it.
>
> 3. Unless a compiler adds some rather sophisticated alloca-related support,
> it precludes the possibility of alloca() using a heap allocation rather
> than a stack allocation in cases where stack memory is scarce.
>
> Having a function which allocates memory take care of releasing it isn't
> hard, and while I could see semantic benefit to having a compiler squawk if
> stack-allocate/stack-free calls aren't balanced, I don't see any upside to
> the implicit freeing of alloca() memory which are even remotely close to
> outweighing the drawbacks.
It is possible to declare a buffer within a local scope and do your own
memory management without resorting to alloca. The only tricky part in
creating your own region allocator is getting the alignment constraints
correct, but I can't see reason why you couldn't do something like this:
\code snippet
int r_levenshtein( const char* s1, const char* s2 )
{
int distance;
size_t m, n;
int* proximity_matrix;
struct c_region pm_region;
unsigned char pm_workspace[sizeof (int) * 64];
bool malloc_used = false;
c_return_value_if_fail( s1 != NULL, -1 );
c_return_value_if_fail( s2 != NULL, -1 );
m = strlen( s1 );
n = strlen( s2 );
/* If one of the strings is empty "", the edit distance is equal to
the length of the non-empty string. */
if ( m == 0 || n == 0 ) {
return m + n;
}
c_region_initialize( &pm_region, pm_workspace, sizeof pm_workspace );
++m;
++n;
proximity_matrix = c_region_allocate( &pm_region,
sizeof (int) * m * n,
alignof (int) );
if ( proximity_matrix == NULL )
{
proximity_matrix = malloc( sizeof (int) * m * n );
malloc_used = true;
}
else {
++small_buffer_optimization;
}
if ( proximity_matrix )
{
gc_compute_levenshtein_matrix( proximity_matrix, m, n, s1, s2 );
distance = proximity_matrix[m*n-1];
if ( malloc_used ) {
free( proximity_matrix );
}
}
else {
distance = -1;
}
return distance;
}
\endcode
I snipped this from some test code where I was experimenting with my
region allocator. It sacrifices the speed of alloca, but has the
capability to "rewind" the region pointer to reclaim memory, and you
still get auto cleanup for smaller string comparisons.
There was a thread a (long) while ago where Chris Thomasson was doing
some region allocation stuff that may be of interest.
Best regards,
John D.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <nospam@nospam.nospam> |
|---|---|
| Date | 2015-07-12 10:17 -0700 |
| Message-ID | <mnu7fa$v6f$1@speranza.aioe.org> |
| In reply to | #65394 |
> "Rick C. Hodgin" wrote in message > news:e9abe69a-2532-44f3-be7b-aaa236783cfb@googlegroups.com... > Does C define a type of lalloc() function for local / stack allocation? > On x86 (which has an expand-down stack): [...] No. However, and FWIW, here is a "hack" at a region allocator I wrote a while back that can be fed with a buffer on the stack: https://groups.google.com/d/msg/comp.lang.C/7oaJFWKVCTw/sSWYU9BUS_QJ http://pastebin.com/f37a23918 Unfortunately, it uses some non-portable trickery wrt alignment... Yikes! ;^o Also, VLA's might be of use to you but I believe they are optional.
[toc] | [prev] | [next] | [standalone]
| From | gordonb.zziiu@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2015-07-27 22:41 -0500 |
| Message-ID | <oJednSrtZtp2ZCvInZ2dnUU7-KWdnZ2d@posted.internetamerica> |
| In reply to | #65394 |
> 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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-28 08:35 -0700 |
| Message-ID | <lnd1zcnvla.fsf@kst-u.example.com> |
| In reply to | #66471 |
gordonb.zziiu@burditt.org (Gordon Burditt) writes:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> 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.
(I re-added an attribution line.)
alloca() is not specific to GNU.
Variable-length arrays were introduced in C99. C11 made them optional.
[...]
> 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.
Does "you" here refer to the compiler? The programmer doesn't have to
keep track of any of this (other than to avoid allocating too much
memory).
> 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.
The Linux alloca(3) man page says:
On many systems alloca() cannot be used inside the list of
arguments of a function call, because the stack space
reserved by alloca() would appear on the stack in the middle
of the space for the function arguments.
(It also says that there's no check for stack overflow; again, the
standard would describe this as undefined behavior.)
> 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 function argument should not include a call to alloca().
> 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.
I've never heard of an implementation that would have problems calling
alloca() in an inner block, and there's no mention of any such problem
in the Linux man page. Do you know of a specific example?
As always, I do not grant permission to quote this article without a
proper attribution line.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.c
csiph-web