470,815 Members | 1,320 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,815 developers. It's quick & easy.

Memory allocation for array

I have a question regarding the memory allocation of array.

For example
int array[10];

Now according to my understanding 10 subsequent memory location will
be allocated of size sizeof(int) *10 and this is done at compile
time.

Does it mean C compiler reserve some amount of memory for the array
at compile time?
That means with out the line of code being executed some amount of
memory is getting exhausted.

I think I am misinterpreting the idea of compile time memory
allocation.
Please provide some inputs to correct my understanding.

--
Somenath
Jun 27 '08 #1
4 2313
somenath wrote:
I have a question regarding the memory allocation of array.

For example
int array[10];

Now according to my understanding 10 subsequent memory location will
be allocated of size sizeof(int) *10 and this is done at compile
time.

Does it mean C compiler reserve some amount of memory for the array
at compile time?
The C standard doesn't specify how memory is allocated, so the answer is
likely to vary between implementations.

Having said that, if the array is a local object it is most likely
allocated on a hardware stack provided by the system. In this case
the "space" for the array doesn't exist until the machine instructions
that allocate the space on the stack are encountered. This will
typically be some type of SUB SP,NNN or a series of PUSH instructions.
They will be executed each time the block (or function) is entered and
the opposite clean-up instructions (POP or more likely ADD SP,NNN) will
be executed when the block (or function) is about to be left.

I suppose that allocating memory for local objects from a software stack
would be considerably different. I have not encountered any C compiler
do such a thing, but an interpreter is likely to employ this method.

If your array is a static or file scope object, then the "space" for it
most likely "coded" into the executable itself in some way, either by
actually reserving the necessary bytes or through special instructions
to the program loader which then allocates the memory before the
program is started. The details are likely to vary quite a lot between
systems.
That means with out the line of code being executed some amount of
memory is getting exhausted.
I think you might want to reconsider this.
I think I am misinterpreting the idea of compile time memory
allocation. Please provide some inputs to correct my understanding.
It's hard to provide more input without actually considering an
implementation, and that is off-topic here. Perhaps you might want to
consult a group for your system, or look-up the online version of the
book /Linkers and Loaders/ by Levine, which deals with some aspects of
your question. Also read about stack frames.

Jun 27 '08 #2
somenath wrote:
I have a question regarding the memory allocation of array.

For example
int array[10];

Now according to my understanding 10 subsequent memory location will
be allocated of size sizeof(int) *10 and this is done at compile
time.

Does it mean C compiler reserve some amount of memory for the array
at compile time?
That means with out the line of code being executed some amount of
memory is getting exhausted.

I think I am misinterpreting the idea of compile time memory
allocation.
Please provide some inputs to correct my understanding.

--
Somenath
No. real physical memory is not used until program is loaded (executed).
The compiler (including assembler and linker) just puts instructions
in executable file about how much physical memory should be reserved for
the array should this piece of code ever get executed.

Tejas Kokje
Jun 27 '08 #3
On 18 Jun 2008 at 16:31, Tejas Kokje wrote:
somenath wrote:
>int array[10];
No. real physical memory is not used until program is loaded (executed).
The compiler (including assembler and linker) just puts instructions
in executable file about how much physical memory should be reserved for
the array should this piece of code ever get executed.
That's a reasonable explanation when array is an automatic variable,
though in that case it's slightly misleading to say that "memory is
reserved", since the array will probably occupy different memory
addresses on the stack each time the containing function is called.

If array is a static variable, then it's true to say that a specific
fixed array of memory is reserved for it in the bss segment, but it's
slightly misleading to talk about the code being "executed" in that case
- we usually think of this sort of memory setup "just happening" before
the execution of main() begins.

Jun 27 '08 #4
somenath wrote:
I have a question regarding the memory allocation of array.

For example
int array[10];

Now according to my understanding 10 subsequent memory location will
be allocated of size sizeof(int) *10 and this is done at compile
time.

Does it mean C compiler reserve some amount of memory for the array
at compile time?
Compiler does not literally "allocate" this memory, of course, since it
will only be allocated when the program is executed. When someone says
that the memory is "allocated" at compile time, it really means that the
memory layout can be determined and hardcoded at compile time. I.e. it
really means that the compiler has enough information to predict the
memory layout (location, size, etc) for these variables with the level
of certainty that permits it to hardcode the absolute (or relative)
address of the variable in the actual code. (As opposed to obtaining,
storing and later using an "unpredictable" address in a pointer
variable). This is possible with static variables (which are normally
located at fixed absolute address, known at compile time) and automatic
variables (which are normally located at fixed offset from the beginning
of the function stack frame, known at compile time).

--
Best regards,
Andrey Tarasevich
Jun 27 '08 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

11 posts views Thread by Michael B. Allen | last post: by
6 posts views Thread by Rex_chaos | last post: by
74 posts views Thread by ballpointpenthief | last post: by
81 posts views Thread by Peter Olcott | last post: by
9 posts views Thread by weidongtom | last post: by
reply views Thread by mihailmihai484 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.