Heap Vs Stack

Discussion in 'C Programming' started by Nehil, Jul 8, 2007.

  1. Nehil

    Nehil Guest

    I would like to know which is dynamic in nature.
    if i refer the C memory model (Richard Steven), it is shown that both
    stack and heap grow towards each other.
    Now, can one go into other's area and hence effecting the size of
    other memory area.

    Does any limit exist upto which a stack or a heap can grow. and if it
    is there then who decides the limit?

    plz clarify.
    Nehil, Jul 8, 2007
    #1
    1. Advertising

  2. Nehil

    santosh Guest

    Nehil wrote:

    > I would like to know which is dynamic in nature.
    > if i refer the C memory model (Richard Steven), it is shown that both
    > stack and heap grow towards each other.
    > Now, can one go into other's area and hence effecting the size of
    > other memory area.
    >
    > Does any limit exist upto which a stack or a heap can grow. and if it
    > is there then who decides the limit?
    >
    > plz clarify.


    The C Standard does not even define the terms "stack" and "heap",
    though they're common in most computing architectures. This group only
    discusses C as defined by it's Standard and hence your questions are
    not topical.

    Having said that, the nature of the stack and the heap, if one or both
    do exist, usually have more to do with the system's hardware
    architecture and it's operating system than a normal C program. So
    possible answers to your questions are dependent upon the details of
    your system, it's system software and it's C implementation. Post to
    an appropriate group, (for example a Windows or Unix programming
    group).
    santosh, Jul 8, 2007
    #2
    1. Advertising

  3. In article <>,
    Nehil <> wrote:
    >I would like to know which is dynamic in nature.
    >if i refer the C memory model (Richard Steven), it is shown that both
    >stack and heap grow towards each other.
    >Now, can one go into other's area and hence effecting the size of
    >other memory area.
    >
    >Does any limit exist upto which a stack or a heap can grow. and if it
    >is there then who decides the limit?
    >
    >plz clarify.


    http://groups.google.com/groups?q=stack heap group:comp.lang.c


    dave

    --
    Dave Vandervies
    A truly intelligent animal would try to act as if it were not intelligent,
    at least when around humans.
    --Richard Heathfield in comp.programming
    Dave Vandervies, Jul 8, 2007
    #3
  4. Nehil

    Nehil Guest

    To all :
    Thanks a lot for ur answers.

    ===================================================================================================

    Well, i understand that standards say nothing about these two terms
    and they are implementation specific.

    may i know who implements the C standard : is it compiler, linker,
    loader, OS or some combination of these with some collaboration.

    plz look at the following program :

    int i=0;
    int main(void)
    {
    i++;
    printf("%d\n",i);
    main();
    return 0;
    }

    each time the the program is executed, with same binary/exe or
    different (i.e. by compiling again) the value of i is different.
    on what factors the value of i last printed, depends upon.
    plea

    please clarify.

    ===================================================================================================
    Nehil, Jul 8, 2007
    #4
  5. Nehil

    santosh Guest

    Nehil wrote:

    > To all :
    > Thanks a lot for ur answers.
    >
    > Well, i understand that standards say nothing about these two terms
    > and they are implementation specific.


    Er, which two terms? On Usenet it's recommended practise to quote the
    post you're replying to. Most of the participants on this group,
    (nearly all the C experts certainly), do not access the group through
    Google Groups. They access Usenet directly through a newsreader and
    news server. News servers purge older articles periodically, unlike
    Google Groups. Hence it's wise to retain context in all your posts.

    > may i know who implements the C standard : is it compiler, linker,
    > loader, OS or some combination of these with some collaboration.


    The International Standard for C is issued by the ISO. Specifically
    it's Working Group 14 of Subcommittee 22 of Joint Technical Committee
    1.

    <http://www.open-std.org/jtc1/sc22/wg14/>

    National Standards Organisations then adopt it.

    This Standard, (and the accompanying Rationale), is used as the
    guiding document by various compiler and library implementors, when
    creating a Standards conforming implementation. Very few
    implementations have fully implemented the current C Standard - ISO
    9899:1999. Most have implemented most of it.

    > plz look at the following program :
    >
    > int i=0;
    > int main(void)
    > {
    > i++;
    > printf("%d\n",i);
    > main();
    > return 0;
    > }
    >
    > each time the the program is executed, with same binary/exe or
    > different (i.e. by compiling again) the value of i is different.


    That shouldn't be so.

    The above program will recursively call the main function forever,
    since there's no termination condition. In practise it's likely to run
    out of memory and get terminated.
    santosh, Jul 8, 2007
    #5
  6. Nehil

    santosh Guest

    santosh wrote:

    > Nehil wrote:


    <snip>

    > > plz look at the following program :
    > >
    > > int i=0;
    > > int main(void)
    > > {
    > > i++;
    > > printf("%d\n",i);
    > > main();
    > > return 0;
    > > }
    > >
    > > each time the the program is executed, with same binary/exe or
    > > different (i.e. by compiling again) the value of i is different.

    >
    > That shouldn't be so.
    >
    > The above program will recursively call the main function forever,
    > since there's no termination condition. In practise it's likely to run
    > out of memory and get terminated.


    Of course, the program as presented by Nehil will invoke undefined
    behaviour. To make it defined stdio.h has to be included.
    santosh, Jul 8, 2007
    #6
  7. On Sun, 08 Jul 2007 13:44:22 -0000, in comp.lang.c , Nehil
    <> wrote:

    >may i know who implements the C standard : is it compiler, linker,
    >loader, OS or some combination of these with some collaboration.


    All of them, probably.

    >plz look at the following program :
    >
    >int i=0;
    >int main(void)
    >{
    >i++;
    >printf("%d\n",i);
    >main();
    >return 0;
    >}
    >
    >each time the the program is executed, with same binary/exe or
    >different (i.e. by compiling again) the value of i is different.


    Because you have forgotten to #include stdio.h, and so the behaviour
    is undefined. include the header and try again.

    Note that the programme will continue indefinitely, or until you run
    out of memory.

    --
    Mark McIntyre

    "Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it."
    --Brian Kernighan
    Mark McIntyre, Jul 8, 2007
    #7
  8. "Nehil" <> wrote in message
    news:...
    >I would like to know which is dynamic in nature.
    > if i refer the C memory model (Richard Steven), it is shown that both
    > stack and heap grow towards each other.
    > Now, can one go into other's area and hence effecting the size of
    > other memory area.
    >
    > Does any limit exist upto which a stack or a heap can grow. and if it
    > is there then who decides the limit?
    >

    Assume a typical structured C program consisting of subroutines that call
    each other and pass each other data. As the program grows in size and
    complexity, its stack usage will tend to grow as the logarithm of the number
    of functions it contains. It's heap usage, however, will grow linearly with
    the amount of data it processes. That is beacuse stack variables are thrown
    away when the function exits, heap allocations typically are not.

    Because of the law of logarithms, it follows that you only need a relatively
    small stack, even for a huge program, as long as we impose the rule that,
    say, no one stack item may be more then 1K in size. On the other hand you
    can easily gobble many megabytes of heap space. Another factor is that, if
    the data item is huge, such as a 24-bit rgba image, typically it doesn't
    make much sense to hardcode the dimensions at compile time. If it is small,
    like a chess board, often hardocidng size will make sense. C99 allows
    variable-sized objects on the stack, but generally this is considered to be
    an undesireable feature, becasue it makes it too easy to run yourself out of
    stack space as user enters a maliciously long word.
    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
    Malcolm McLean, Jul 8, 2007
    #8
  9. On Jul 8, 6:44 am, Nehil <> wrote:
    >
    > Well, i understand that standards say nothing about these two terms
    > and they are implementation specific.
    >
    > may i know who implements the C standard : is it compiler, linker,
    > loader, OS or some combination of these with some collaboration.


    Usually a combination of all (in some sense) with some collaboration.
    For example, an implementation will often rely on the linker and the
    loader to ensure that variables which need to be initialized to all-
    bits-zero are initialized correctly when the program starts. The
    loader will often use a facility from the OS to get a chunk of memory
    filled with zero bits.
    J. J. Farrell, Jul 8, 2007
    #9
  10. Mark McIntyre <> writes:
    > On Sun, 08 Jul 2007 13:44:22 -0000, in comp.lang.c , Nehil
    > <> wrote:
    >>may i know who implements the C standard : is it compiler, linker,
    >>loader, OS or some combination of these with some collaboration.

    >
    > All of them, probably.
    >
    >>plz look at the following program :
    >>
    >>int i=0;
    >>int main(void)
    >>{
    >>i++;
    >>printf("%d\n",i);
    >>main();
    >>return 0;
    >>}
    >>
    >>each time the the program is executed, with same binary/exe or
    >>different (i.e. by compiling again) the value of i is different.

    >
    > Because you have forgotten to #include stdio.h, and so the behaviour
    > is undefined. include the header and try again.


    It's true that calling printf without a '#include <stdio.h>' (or a
    declaration for printf) invokes undefined behavior, but in practice
    it's highly unlikely that that explains the behavior he's seeing.

    > Note that the programme will continue indefinitely, or until you run
    > out of memory.


    Assuming the '#include <stdio.h>' is added, there are three
    possibilities I can think of:

    1. The bottomless recursion will cause the program to run out of
    memory after some number of calls. It will print the value of i
    before each call; the last value printed will *probably* give you an
    idea of how many calls occurred. However, running out of memory
    invokes undefined behavior (terminating the program is common, but not
    guaranteed), so there's no way to be certain. If you see different
    numbers on successive invocations, it can be for any number of
    reasons. The program may have different amounts of memory available
    for whatever reason, or different amounts of output may have been
    buffered but not yet displayed when the program crashed. (Unless you
    call fflush(stdout) after each printf, you may not see all the
    output.)

    2. 'i' could reach INT_MAX before the program runs out of memory. At
    this point, 'i++' invokes undefined behavior. Wrapping around to
    INT_MIN is a common result, but it's not guaranteed. If it does
    simply wrap around, the program will continue running until it runs
    out of memory; see above.

    2. The compiler may be smart enough to recognize the tail recursion,
    transforming the recursive call into an infinite loop that doesn't
    consume extra memory on each call. When 'i' reaches INT_MAX, the next
    'i++' will invoke undefined behavior; see above. If the program
    continues after this, it will probably keep running until you kill it.

    --
    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."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jul 9, 2007
    #10
  11. "Malcolm McLean" <> writes:
    > "Nehil" <> wrote in message
    > news:...
    >>I would like to know which is dynamic in nature.
    >> if i refer the C memory model (Richard Steven), it is shown that both
    >> stack and heap grow towards each other.
    >> Now, can one go into other's area and hence effecting the size of
    >> other memory area.
    >>
    >> Does any limit exist upto which a stack or a heap can grow. and if it
    >> is there then who decides the limit?
    >>

    > Assume a typical structured C program consisting of subroutines that
    > call each other and pass each other data. As the program grows in size
    > and complexity, its stack usage will tend to grow as the logarithm of
    > the number of functions it contains. It's heap usage, however, will
    > grow linearly with the amount of data it processes. That is beacuse
    > stack variables are thrown away when the function exits, heap
    > allocations typically are not.

    [...]

    You're assuming no recursion. Recursion is common in programs that
    process recursively-defined data; the more complex the input data, the
    deeper the nested function calls. A compiler with a recursive descent
    parser is a good example of this; a program that processes XML is
    probably another.

    --
    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."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jul 9, 2007
    #11
  12. "Keith Thompson" <> wrote in message
    news:...
    > "Malcolm McLean" <> writes:
    >> "Nehil" <> wrote in message
    >> news:...
    >>>I would like to know which is dynamic in nature.
    >>> if i refer the C memory model (Richard Steven), it is shown that both
    >>> stack and heap grow towards each other.
    >>> Now, can one go into other's area and hence effecting the size of
    >>> other memory area.
    >>>
    >>> Does any limit exist upto which a stack or a heap can grow. and if it
    >>> is there then who decides the limit?
    >>>

    >> Assume a typical structured C program consisting of subroutines that
    >> call each other and pass each other data. As the program grows in size
    >> and complexity, its stack usage will tend to grow as the logarithm of
    >> the number of functions it contains. It's heap usage, however, will
    >> grow linearly with the amount of data it processes. That is beacuse
    >> stack variables are thrown away when the function exits, heap
    >> allocations typically are not.

    > [...]
    >
    > You're assuming no recursion. Recursion is common in programs that
    > process recursively-defined data; the more complex the input data, the
    > deeper the nested function calls. A compiler with a recursive descent
    > parser is a good example of this; a program that processes XML is
    > probably another.
    >

    Though even there typically data is designed so that tree depth is pretty
    low. For instance a human-readable C source is not going to have any
    expressions with more than three levels of paretheses, although it may may
    have tens of thousands of such expressions.

    Sometimes you get recursion as a lazy man's iteration, however. Then your
    objection would be valid.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
    Malcolm McLean, Jul 9, 2007
    #12
  13. On Sun, 08 Jul 2007 17:48:06 -0700, in comp.lang.c , Keith Thompson
    <> wrote:

    >It's true that calling printf without a '#include <stdio.h>' (or a
    >declaration for printf) invokes undefined behavior, but in practice
    >it's highly unlikely that that explains the behavior he's seeing.


    I'm inclined to agree, but first fix the obvious problems, then look
    for less obvious ones...

    --
    Mark McIntyre

    "Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it."
    --Brian Kernighan
    Mark McIntyre, Jul 10, 2007
    #13
    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:
    424
    Michael Borgwardt
    Aug 5, 2004
  2. Steve Hill

    vector.swap and heap / stack

    Steve Hill, Aug 20, 2003, in forum: C++
    Replies:
    5
    Views:
    988
    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:
    722
    GArlington
    Mar 25, 2008
  4. viki
    Replies:
    6
    Views:
    556
    Erik Wikström
    Jun 28, 2008
  5. Raymond Schanks
    Replies:
    0
    Views:
    504
    Raymond Schanks
    Apr 11, 2010
Loading...

Share This Page