santosh
8/9/2008 6:46:00 PM
sidd wrote:
> In the following code:
>
> int i = 5; ---> it goes to .data segment
Not necessarily.
> int j; ---> it goes to bss segment
Not necessarily.
> int main()
> {
> int c;
> int i = 5; ---> stack
Not necessarily.
> int j[5] = new int[5]; ----> heap
This is a syntax error in C. If your doing C++ the note that there is a
specialised group for it: comp.lang.c++.
> c = i*2; ----> goes to .text segment
Not necessarily.
> }
>
>
> My question is : When the object file is created there are text, data
> and bss segments etc...but there is notthing like stack and heap
> segment, what happens to these automatic variables ?
>
> I hope I am making sense.....
Firstly, as far as Standard C is concerned, there need be no segments of
any kind at all. In fact, the format of the final executable image
produced by the last translation phase is not specified at all. In
fact, an interpreter that never produces a machine language
representation is also perfectly legal.
The segments you have mentioned are a common system of laying out
executable files, but this is not universal, and even within the
overall scheme, there is a lot of variation in detail.
In general though, automatic objects are placed in some kind of "stack
like" memory (which under most implementations happens to be an actual
hardware assisted stack), while static objects reside elsewhere. The
compiler may also decide to place string literals and const qualified
objects in read-only storage, while memory returned by
malloc/calloc/realloc is usually from the so-called "heap", though
again it must be emphasised that C itself does not require such
classification, though it is commonly used.
For example a C implementation that decides to place all objects on the
heap is perfectly conforming, while one that decides to allocate all
objects on a stack is also perfectly conforming.
To get a more satisfactory answer (though it is not a generic one), you
must examine the details of your implementation, the memory model used
by your operating system, the format of the executable that your
implementation produces etc. An assembly language group might be a
better idea since these sorts of machine level details are often dealt
with there. See comp.lang.asm.x86 if your system is an x86 based one,
or alt.lang.asm for other architectures. If your system is an embedded
one see comp.arch.embedded.