Heap Vs Stack

[Nehil]

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.

 

[santosh]

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).

 

[Dave Vandervies]

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

 

[Nehil]

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.

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

 

[santosh]

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]

Nehil wrote:


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.

 

[Mark McIntyre]

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

 

[Malcolm McLean]

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.

 

[J. J. Farrell]

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.

 

[Keith Thompson]

All of them, probably.


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]

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.

 

[Malcolm McLean]

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.

 

[Mark McIntyre]

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