Stack or Heap

Discussion in 'C Programming' started by bitshadow, Nov 14, 2005.

  1. bitshadow

    bitshadow Guest

    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;
    }
    bitshadow, Nov 14, 2005
    #1
    1. Advertising

  2. 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
    Daniel Fischer, Nov 14, 2005
    #2
    1. Advertising

  3. bitshadow

    barbaros Guest

    trivial code using getline under gcc

    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
    barbaros, Nov 14, 2005
    #3
  4. Re: trivial code using getline under gcc

    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
    Daniel Fischer, Nov 14, 2005
    #4
  5. Re: trivial code using getline under gcc

    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
    David Resnick, Nov 14, 2005
    #5
  6. bitshadow

    Tim Prince Guest

    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.
    Tim Prince, Nov 14, 2005
    #6
  7. C99 VLAs (was Re: Stack or Heap)

    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:>
    Kenneth Brody, Nov 14, 2005
    #7
  8. Re: C99 VLAs (was Re: Stack or Heap)

    Kenneth Brody <> 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) <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.
    Keith Thompson, Nov 14, 2005
    #8
  9. bitshadow

    Jordan Abel Guest

    Re: C99 VLAs (was Re: Stack or Heap)

    On 2005-11-14, Keith Thompson <> wrote:
    > Kenneth Brody <> 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.
    Jordan Abel, Nov 14, 2005
    #9
  10. bitshadow

    bitshadow Guest

    > 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.
    bitshadow, Nov 14, 2005
    #10
  11. >> 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
    Gordon Burditt, Nov 14, 2005
    #11
  12. bitshadow

    Jordan Abel Guest

    On 2005-11-14, Gordon Burditt <> 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.
    Jordan Abel, Nov 15, 2005
    #12
  13. bitshadow

    bitshadow Guest

    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.
    bitshadow, Nov 15, 2005
    #13
  14. (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) <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.
    Keith Thompson, Nov 15, 2005
    #14
  15. bitshadow

    Jack Klein Guest

    Re: C99 VLAs (was Re: Stack or Heap)

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

    > On 2005-11-14, Keith Thompson <> wrote:
    > > Kenneth Brody <> 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/~ajo/docs/FAQ-acllc.html
    Jack Klein, Nov 15, 2005
    #15
  16. 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
    Daniel Fischer, Nov 15, 2005
    #16
  17. Daniel Fischer <> 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) <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.
    Keith Thompson, Nov 15, 2005
    #17
  18. Re: C99 VLAs (was Re: Stack or Heap)

    Keith Thompson wrote:
    >
    > Kenneth Brody <> 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:>
    Kenneth Brody, Nov 15, 2005
    #18
  19. bitshadow

    Imre Palik Guest

    Re: C99 VLAs (was Re: Stack or Heap)

    Kenneth Brody <> 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
    Imre Palik, Nov 16, 2005
    #19
  20. bitshadow

    pete Guest

    Re: C99 VLAs (was Re: Stack or Heap)

    Imre Palik wrote:
    >
    > Kenneth Brody <> 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
    pete, Nov 16, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. joe

    stack and heap question

    joe, Aug 4, 2004, in forum: Java
    Replies:
    3
    Views:
    429
    Michael Borgwardt
    Aug 5, 2004
  2. Steve Hill

    vector.swap and heap / stack

    Steve Hill, Aug 20, 2003, in forum: C++
    Replies:
    5
    Views:
    1,001
    tom_usenet
    Aug 22, 2003
  3. Michal Slocinski

    Heap dump file size vs heap size

    Michal Slocinski, Mar 25, 2008, in forum: Java
    Replies:
    1
    Views:
    732
    GArlington
    Mar 25, 2008
  4. viki
    Replies:
    6
    Views:
    561
    Erik Wikström
    Jun 28, 2008
  5. Raymond Schanks
    Replies:
    0
    Views:
    518
    Raymond Schanks
    Apr 11, 2010
Loading...

Share This Page