Stack or Heap

[bitshadow]

using the following code, i was able to have my compiler seg fault on
me when i gave the argument as anythng greater than 20,832,000bytes. In
the case of the struct its 868 instances of said structure. The
compiler obviously allows VLA however it craps out after the above
amount of bytes.
I was told i was attempting to put everythng on the stack and not the
heap. So i was wondering if anyone can maybe clear it up, is that true?
would i have to then malloc 868 instances of that struct when needed to
avoid a seg fault? what exactly is the stack and the heap, i've never
really gotten around to that yet?

code:
/*program illustrates devc++ ability to create a VLA.*/

#include<stdio.h>
#include<string.h>
#define SIZE 200
#define MAX_CLMS 12

typedef struct{
char info[SIZE];
}CLMS
typedef struct{
CLMS clm[MAX_CLMS];
}PERSON;
int main(){
printf("how many arrays?");
int num;int n=0;

scanf("%d", &num);
PERSON array[num];

int x[num];

for(n=0;n<num;n++)
x[n]=n;

for(n=0;n<num;n++)
printf("%d\n",x[n]);
main(); /*for testing purposes*/

getchar();getchar();

return 0;
}

[Daniel Fischer]

Hi,

On Mon, 14 Nov 2005 07:01:32 -0800, bitshadow wrote:

I was told i was attempting to put everythng on the stack and not the
heap. So i was wondering if anyone can maybe clear it up, is that true?
that's generally the case with all local variables.
would i have to then malloc 868 instances of that struct when needed to
avoid a seg fault?
To avoid a seg fault, you need to fall back to malloc (how we did it
before C99's VLAs) and don't forget proper error handling and freeing the
memory when you don't need it anymore. It's not really more complicated,
just doesn't look as nice.
what exactly is the stack and the heap, i've never really gotten around
to that yet?

Basically, they're just two different areas in memory. Globally available
memory is allocated from the heap and the stack is used for locally
available memory, return addresses, parameter passing and the like. Memory
coming out of the heap is allocated in more or less arbitrarily sized
blocks, while the stack consists of one large block and a pointer into it
that is moved whenever memory is allocated or freed. Typically, returning
from a function will return the stack pointer to the position before the
function was invoked, automagically freeing all memory allocated on the
stack since then. On platforms that can't grow the stack, stack space is
consequently limited.

This is not always the case. Some operating systems (like some versions
of Linux) grow the stack area from the bottom of addressable memory and
the heap area from the top, or employ any of a number of similar schemes.
Daniel

[barbaros]

Hi everybody. I know this will look trivial for most of you.
I apologize for that, but I am out of ideas.
The code below compiles well but gives segmentation fault at execution.
Looks like getline is giving trouble. I use debian linux, gcc.

#include <stdlib.h>
int main () {
char line[256];
int n;
printf("Type an integer:\n");
getline(line, 256);
n = atoi(line);
}

Thank you. Cristian Barbarosie
http://cmaf.fc.ul.pt/~barbaros

[Daniel Fischer]

On Mon, 14 Nov 2005 08:09:22 -0800, barbaros wrote:

The code below compiles well but gives segmentation fault at execution.
Looks like getline is giving trouble. I use debian linux, gcc.

Your problems are 1. that getline() is not standard C and 2. that it doesn
t work like you thought it did. Read 'man getline' - it has an example.
Daniel

[David Resnick]

barbaros wrote:

Hi everybody. I know this will look trivial for most of you.
I apologize for that, but I am out of ideas.
The code below compiles well but gives segmentation fault at execution.
Looks like getline is giving trouble. I use debian linux, gcc.

#include <stdlib.h>
int main () {
char line[256];
int n;
printf("Type an integer:\n");
getline(line, 256);
n = atoi(line);
}

Thank you. Cristian Barbarosie
http://cmaf.fc.ul.pt/~barbaros

printf is not in stdlib.h. getline is not a standard function at all.
To remain on topic for clc, a generally helpful thing to say is that
enabling compiler warnings on your sytem can help you solve your
own problems better. For example, on my system If I do

gcc -Wall -o foo foo.c
foo.c: In function `main':
foo.c:5: warning: implicit declaration of function `printf'
foo.c:6: warning: implicit declaration of function `getline'
foo.c:8: warning: control reaches end of non-void function

Fix those up and things may go better for you.

-David

[Tim Prince]

bitshadow wrote:

using the following code, i was able to have my compiler seg fault on
me when i gave the argument as anythng greater than 20,832,000bytes. In
the case of the struct its 868 instances of said structure. The
compiler obviously allows VLA however it craps out after the above
amount of bytes.
I was told i was attempting to put everythng on the stack and not the
heap. So i was wondering if anyone can maybe clear it up, is that true?
would i have to then malloc 868 instances of that struct when needed to
avoid a seg fault? what exactly is the stack and the heap, i've never
really gotten around to that yet?

As your problem appears to occur when your VLA reaches a size of 2GB, it
may indicate that you are attempting to run on a system which does not
support larger VLA. If you are running on an x86-64 system, this limit
might be affected by a build option such as -mcmodel. If on a 32-bit
system, there may not be a good alternative.

[Kenneth Brody]

bitshadow wrote:
[...]

int main(){ [...] scanf("%d", &num);
PERSON array[num];

int x[num];

[...]

When using malloc(), failure is indicated by a NULL return value. How
does C99 indicate failure to allocate memory for VLAs?

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Keith Thompson]

Kenneth Brody <ke******@spamcop.net> writes:

bitshadow wrote:
[...]

int main(){

[...]

scanf("%d", &num);
PERSON array[num];

int x[num];

[...]

When using malloc(), failure is indicated by a NULL return value. How
does C99 indicate failure to allocate memory for VLAs?

It doesn't. If a VLA exceeds available memory, it invokes undefined
behavior.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Jordan Abel]

On 2005-11-14, Keith Thompson <ks***@mib.org> wrote:

Kenneth Brody <ke******@spamcop.net> writes:

bitshadow wrote:
[...]

int main(){

[...]

scanf("%d", &num);
PERSON array[num];

int x[num];

[...]

When using malloc(), failure is indicated by a NULL return value. How
does C99 indicate failure to allocate memory for VLAs?

It doesn't. If a VLA exceeds available memory, it invokes undefined
behavior.

In any case, on any reasonable implementation it will be something
similar to what happens with an ordinary stack overflow.

[bitshadow]

> Basically, they're just two different areas in memory. Globally available

memory is allocated from the heap and the stack is used for locally
available memory, return addresses, parameter passing and the like. Memory
coming out of the heap is allocated in more or less arbitrarily sized
blocks

is it that the stack then is your available RAM and the heap is your
available storage on your HD, or is that just an anlogy? if you know
any resources on the web i'd appreciate that, i don't seem to be lucky
on google.

Thank you all for responding in anycase. I'm not really a big fan of
c99 features, but VLA'S seem like they should have just been in c89,
they are pretty helpful. Can't say much for the other features as they
seem redundant,cluttering and unnecessary.

[Gordon Burditt]

>> Basically, they're just two different areas in memory. Globally available

memory is allocated from the heap and the stack is used for locally
available memory, return addresses, parameter passing and the like. Memory
coming out of the heap is allocated in more or less arbitrarily sized
blocks

The heap is sometimes defined as "that place from which malloc()
allocates its memory". Standard C doesn't provide any guidance on
this. However, in common implementations, global variables, string
literals, code, and static variables are not considered part of
"the heap" nor part of "the stack".

"The stack" is a misnomer since some implementations don't have one.
What is being referred to includes auto variables, function activation
records (return addresses, saved registers & such) and passed
parameters.
is it that the stack then is your available RAM and the heap is your
available storage on your HD, or is that just an anlogy?
It's an extremely BAD analogy: there's no necessary speed difference
between "stack" and "heap", nor do they need to actually be separate,
although they often are. Both of them may have pages swapped out
to disk. Think of it as a zoning ordinance for memory: this memory
is zoned for automatic variables, this other memory is zoned for
dynamic allocation, and this other memory is zoned for loading the
program.
if you know
any resources on the web i'd appreciate that, i don't seem to be lucky
on google.

Thank you all for responding in anycase. I'm not really a big fan of
c99 features, but VLA'S seem like they should have just been in c89,
they are pretty helpful. Can't say much for the other features as they
seem redundant,cluttering and unnecessary.

VLAs have the rather severe problem that there is no way to detect
or report running out of memory.

Gordon L. Burditt

[Jordan Abel]

On 2005-11-14, Gordon Burditt <go***********@burditt.org> wrote:

Thank you all for responding in anycase. I'm not really a big fan of
c99 features, but VLA'S seem like they should have just been in c89,
they are pretty helpful. Can't say much for the other features as they
seem redundant,cluttering and unnecessary.

VLAs have the rather severe problem that there is no way to detect
or report running out of memory.

Gordon L. Burditt

Normal arrays don't have any way to either.

int main() {
unsigned char foo[256] = { 0 };
return main();
}

now, inevitably, that will run out of memory.

[bitshadow]

Gordon Burditt wrote

The heap is sometimes defined as "that place from which malloc()
allocates its memory". Standard C doesn't provide any guidance on
this. However, in common implementations, global variables, string
literals, code, and static variables are not considered part of
"the heap" nor part of "the stack".

"The stack" is a misnomer since some implementations don't have one.
What is being referred to includes auto variables, function activation
records (return addresses, saved registers & such) and passed
parameters.

thanks for clearing that up gordon, i was coming back to ask those
questions- specifiaclly about malloc.

On reviewing my book (c primer plus 4ed) I realised it actaully spoke
about allocating structs that might be too big for the stack - though
it doesn't go too much into what that is. The solutions it presented
are making the array of structs smaller, setting my compiler stack
allowable size to something bigger or make the array static or external
- something that would not help my code.

In either case it seems best to just stick with c89 and simply use
malloc 1)because c99 still isn't widely supported and 2) as you pointed
out with VLA's it can be difficult to see if you have available memory
or not.

thank you again.

[Keith Thompson]

go***********@burditt.org (Gordon Burditt) writes:

Basically, they're just two different areas in memory. Globally available
memory is allocated from the heap and the stack is used for locally
available memory, return addresses, parameter passing and the like. Memory
coming out of the heap is allocated in more or less arbitrarily sized
blocks

The heap is sometimes defined as "that place from which malloc()
allocates its memory". Standard C doesn't provide any guidance on
this. However, in common implementations, global variables, string
literals, code, and static variables are not considered part of
"the heap" nor part of "the stack".

"The stack" is a misnomer since some implementations don't have one.
What is being referred to includes auto variables, function activation
records (return addresses, saved registers & such) and passed
parameters.

Well, yes and no. There are at least two different meanings of the
word "stack". All C implementations need to have some kind of
stack-like structure, in the sense that memory is allocated in a
last-in first-out (LIFO) manner.

But it needn't be a "stack" in the sense referred to on the machine
level. Many machines have hardware support for a contiguous stack,
supported by a dedicated register pointing to the "top" of the stack
and special instructions and/or addressing modes for pushing and
popping data. This is a very common way to implement C's automatic
storage (parameters, local variables, etc), but it's not the only way.
An implementation could also create a linked list of heap-allocated
blocks of memory, one for each function invocation. This would be a
stack in the sense that it's LIFO, but it wouldn't be contiguous,
growing in a specific direction in memory.

In fact, the C standard doesn't use the terms "stack" or "heap", and
we try to avoid them in this newsgroup.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Jack Klein]

On Mon, 14 Nov 2005 21:40:10 +0000 (UTC), Jordan Abel
<jm****@purdue.edu> wrote in comp.lang.c:

On 2005-11-14, Keith Thompson <ks***@mib.org> wrote:

Kenneth Brody <ke******@spamcop.net> writes:

bitshadow wrote:
[...]
int main(){
[...]
scanf("%d", &num);
PERSON array[num];

int x[num];
[...]

When using malloc(), failure is indicated by a NULL return value. How
does C99 indicate failure to allocate memory for VLAs?

It doesn't. If a VLA exceeds available memory, it invokes undefined
behavior.

In any case, on any reasonable implementation it will be something
similar to what happens with an ordinary stack overflow.

....which is also undefined behavior, and under an OS with memory
management the common result is the OS emitting a nasty message and
terminating the offending executable.

But that's just the fun you can have in the wild, wacky, and
unpredictable world of UB.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Daniel Fischer]

On Tue, 15 Nov 2005 00:07:47 +0000, Jordan Abel wrote:

VLAs have the rather severe problem that there is no way to detect
or report running out of memory.

Normal arrays don't have any way to either.

The difference being, of course, that it's much easier to know when normal
arrays will run out of memory beforehand than with VLAs.
I, personally, like VLAs because they remind me of Dutch food similar to
custard.
Daniel

[Keith Thompson]

Daniel Fischer <sp**@erinye.com> writes:

On Tue, 15 Nov 2005 00:07:47 +0000, Jordan Abel wrote:

VLAs have the rather severe problem that there is no way to detect
or report running out of memory.

Normal arrays don't have any way to either.

The difference being, of course, that it's much easier to know when normal
arrays will run out of memory beforehand than with VLAs.

Oh? How?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Kenneth Brody]

Keith Thompson wrote:

Kenneth Brody <ke******@spamcop.net> writes:

bitshadow wrote:
[...]

int main(){

[...]

scanf("%d", &num);
PERSON array[num];

int x[num];

[...]

When using malloc(), failure is indicated by a NULL return value. How
does C99 indicate failure to allocate memory for VLAs?

It doesn't. If a VLA exceeds available memory, it invokes undefined
behavior.

So the advantage over malloc/free, other than the implicit release of the
memory, is...???

While the misuse of a NULL pointer invokes UB, at least you can check the
return from malloc.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Imre Palik]

Kenneth Brody <ke******@spamcop.net> writes:

Keith Thompson wrote:

It doesn't. If a VLA exceeds available memory, it invokes undefined
behavior.

So the advantage over malloc/free, other than the implicit release of the
memory, is...???

speed

[pete]

Imre Palik wrote:

Kenneth Brody <ke******@spamcop.net> writes:

Keith Thompson wrote:

It doesn't.
If a VLA exceeds available memory, it invokes undefined
behavior.

So the advantage over malloc/free,
other than the implicit release of the
memory, is...???

speed

I would actually expect VLA's to implemented under the hood,
as a malloc call with a free at the end of the block,
and some kludge to accomodate the sizeof operator.

--
pete

[Skarmander]

pete wrote:

Imre Palik wrote:

Kenneth Brody <ke******@spamcop.net> writes:

Keith Thompson wrote:

It doesn't.
If a VLA exceeds available memory, it invokes undefined
behavior.

So the advantage over malloc/free,
other than the implicit release of the
memory, is...???

speed

I would actually expect VLA's to implemented under the hood,
as a malloc call with a free at the end of the block,
and some kludge to accomodate the sizeof operator.

Unless the platform has the equivalent of alloca(), of course.

Even without it, it is very likely that for local allocations
specialized versions of malloc() will provide some benefit.

S.

[Keith Thompson]

pete <pf*****@mindspring.com> writes:

Imre Palik wrote:

Kenneth Brody <ke******@spamcop.net> writes:

> Keith Thompson wrote:
> > It doesn't.
> > If a VLA exceeds available memory, it invokes undefined
> > behavior.
>
> So the advantage over malloc/free,
> other than the implicit release of the
> memory, is...???

speed

I would actually expect VLA's to implemented under the hood,
as a malloc call with a free at the end of the block,
and some kludge to accomodate the sizeof operator.

I wouldn't, though it's certainly a possible implementation. I'd
expect VLAs to be implemented on most platforms by extending the
stack, in a manner very similar to allocating an ordinary (fixed-size)
stack frame or calling the non-standard function alloca().

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[jacob navia]

pete a écrit :

Imre Palik wrote:

Kenneth Brody <ke******@spamcop.net> writes:

Keith Thompson wrote:

It doesn't.
If a VLA exceeds available memory, it invokes undefined
behavior.

So the advantage over malloc/free,
other than the implicit release of the
memory, is...???

speed

I would actually expect VLA's to implemented under the hood,
as a malloc call with a free at the end of the block,
and some kludge to accomodate the sizeof operator.

lcc-win32 implements it by extending the stack. This is tricky
under windows since if you allocate more than 4096 bytes you
should implement a loop touching each page at least once to make the
stack grow...