where do the automatic variables go ?

[CBFalconer]

int main()
{
int c;
int i = 5; ---> stack
int j[5] = new int[5]; ----> heap
c = i*2; ----> goes to .text segment
}

This is a misleading dichotomy. The new line will almost certainly
generate instructions too, which will be placed in the .text
segment: new needs to call malloc() to get its memory, which will
indeed be taken from the heap.

[...]

Umm. NO, because I have created a 100% conforming malloc impl for
an embedded system with no heap:

http://groups.google.com/group/comp.lang.c++.moderated/msg/ef7314c3f55495ac

Twink is a pure troll. Please don't encourage him/her/it.

 

[Antoninus Twink]

You act as if the stack will always grow downwards; why?


You seem to suggest that platforms are forced to do such a thing; why?

I suggest no such thing. I simply point out that that is what happens on
Linux/x86, which is what the OP asked about.

 

[Stephen Sprunk]

Thanks for the wonderful links and explanations, but I guess my
question still remains unanswered. My question was that when the code
is compiled and converted to a.out, what happens to the automatic
variables, in other words can someone elaborate more about the
generation of stack frames. I understand that whenever a function is
called, a stack frame gets generated but how are the details of that
routine laid out in the a.out file. In other words where do the
automatic variables part of the routine lie in the a.out format.

<OT>
Automatic variables do not exist in the executable file, in the sense
that you seem to be meaning. They are created on the stack at runtime
as needed, assuming the compiler doesn't put them into registers or
completely optimize them away. Globals and statics can be put in a
fixed part of the executable, since exactly one copy of them will exist
for the entire duration of the program, but that is not true of
automatic variables. Think about recursion in particular; each instance
of the function needs its own copy of any automatic variables.

How a stack frame is created will vary depending on the particular
processor and perhaps OS that you are using. The best thing you can do
is direct your compiler to produce unoptimized assembly code instead of
an executable (e.g. gcc -S -O0) and try to understand the output. On
every system I'm aware of, each function will have a standard "prologue"
at the beginning and "epilogue" at the end. These are what set up and
destroy the stack frame, among other things. If the compiler needs
space on the stack for automatic variables, you will see a small
variation in those two sections to account for the extra space needed.
</OT>

S

 

[Flash Gordon]

Antoninus Twink wrote, On 10/08/08 14:29:

I suggest no such thing. I simply point out that that is what happens on
Linux/x86, which is what the OP asked about.

The OP asked about Linux, not necessarily Linux on an x86, and I have a
desktop Linux box where the stack grows up.