Dynamic memory allocation stack heaps

[vivek]

i have some doubts on dynamic memory allocation and stacks and heaps

where is the dynamic memory allocation used?

in function calls there are some counters like "i" in the below
function. Is this stored in stack. If yes whether it will be deleted
on exiting from the function.

is dynamic memory allocation needed for this purpose

int listnum()
{
unsigned char i;
for(i=0;i>10;i++)
}

 

[Chris Dollin]

vivek wrote:

[Post-hoc I wonder if this is homework. Oh well.]

i have some doubts on dynamic memory allocation and stacks and heaps

where is the dynamic memory allocation used?

Where static or stack (in C, "auto[matic]") allocation isn't appropriate:
eg the size of store needed isn't known in advance, or the memory must be
available for longer than the lifetime of the function which allocated
it.

["Dynamic" allocation is ambiguous. Stack aka auto allocation is dynamic;
variables come into existence when their function is entered and are
no longer accessible when it exits. People often, but not invariably,
mean something like malloc/free or heap allocation when they say
"dynamic".]

in function calls there are some counters like "i" in the below
function. Is this stored in stack. If yes whether it will be deleted
on exiting from the function.

is dynamic memory allocation needed for this purpose

int listnum()
{
unsigned char i;
for(i=0;i>10;i++)

Oops, missing loop body. We'll pretend you wrote `{}` after the `)`.

}

The variable `i` is automatic and is local to the execution(s) of `listnum`.
A typical implementation will allocate it on a stack, but this isn't
required by the Standard, just convenient. So it's dynamic memory
allocation -- just not /very/ dynamic.

When the function exits, the variable becomes inaccessible. (That is,
what happens if you try to access it -- eg through a pointer you got
when the variable was accessible -- is Not Defined, which means that
you Do Not Know what will happen.) Whether that counts as the variable
being "deleted" depends on what you mean by "deleted". Typically the
store used for that version of the variable will be used for something
else.

 

[vivek]

vivek wrote:

[Post-hoc I wonder if this is homework. Oh well.]

i have some doubts on dynamic memory allocation and stacks and heaps

where is the dynamic memory allocation used?

Where static or stack (in C, "auto[matic]") allocation isn't appropriate:
eg the size of store needed isn't known in advance, or the memory must be
available for longer than the lifetime of the function which allocated
it.

["Dynamic" allocation is ambiguous. Stack aka auto allocation is dynamic;
variables come into existence when their function is entered and are
no longer accessible when it exits. People often, but not invariably,
mean something like malloc/free or heap allocation when they say
"dynamic".]

in function calls there are some counters like "i" in the below
function. Is this stored in stack. If yes whether it will be deleted
on exiting from the function.

is dynamic memory allocation needed for this purpose

int listnum()
{
unsigned char i;
for(i=0;i>10;i++)

Oops, missing loop body. We'll pretend you wrote `{}` after the `)`.

}

The variable `i` is automatic and is local to the execution(s) of `listnum`.
A typical implementation will allocate it on a stack, but this isn't
required by the Standard, just convenient. So it's dynamic memory
allocation -- just not /very/ dynamic.

When the function exits, the variable becomes inaccessible. (That is,
what happens if you try to access it -- eg through a pointer you got
when the variable was accessible -- is Not Defined, which means that
you Do Not Know what will happen.) Whether that counts as the variable
being "deleted" depends on what you mean by "deleted". Typically the
store used for that version of the variable will be used for something
else.

--
Chris "static is bad for chips -- hence vinegar" Dollin

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

Thanks. Typically which data are stored on the heap.

 

[Chris Dollin]

Thanks. Typically which data are stored on the heap.

Data that can't be allocated statically or automatically. I'm not sure
what "typically" would be here.

[It also depends on what you mean by "the heap", since the Standard doesn't
talk about a heap; you can say that in C, "the heap" is the memory managed
by malloc/realloc/free, which leads to the unilluminating answer "data
allocated by malloc or realloc" ...]

 

[Mark Bluemel]

Thanks. Typically which data are stored on the heap.

Data that can't be allocated statically or automatically. I'm not sure
what "typically" would be here.

[It also depends on what you mean by "the heap", since the Standard doesn't
talk about a heap; you can say that in C, "the heap" is the memory managed
by malloc/realloc/free, which leads to the unilluminating answer "data
allocated by malloc or realloc" ...]

On at least one system I work on, thread stacks are allocated from the
heap, so automatic data is also in heap space...

 

[Chris Dollin]

Thanks. Typically which data are stored on the heap.

Data that can't be allocated statically or automatically. I'm not sure
what "typically" would be here.

[It also depends on what you mean by "the heap", since the Standard doesn't
talk about a heap; you can say that in C, "the heap" is the memory managed
by malloc/realloc/free, which leads to the unilluminating answer "data
allocated by malloc or realloc" ...]

On at least one system I work on, thread stacks are allocated from the
heap, so automatic data is also in heap space...

(fx:weasel) Fortunately, Standard C doesn't have threads.

Unfortunately, at least one C implementation handles stack overflow by
grabbing another block of memory from whatever-underlies-malloc and
linking it in to a chain of stack chunks, so (at least some) automatic
memory is mallocated.

Conclusion: It All Depends On Why It Matters.

Vivek, what difference do the answers make to what you do?

 

[Podi]

I found this http://www.cs.uleth.ca/~holzmann/C/system/memorylayout.pdf
quite handy for general understanding.

My group is hiring multiple SW engineers and I've interviewed many
experienced SW engineers. Believe it or not, my impression have been
that 8 out 10 people don't know about this.

 

[Jack Klein]

i have some doubts on dynamic memory allocation and stacks and heaps

C doesn't define stacks or heaps, nor are C compilers required to use
them.

where is the dynamic memory allocation used?

When you call memory allocation functions malloc(), realloc(), or
calloc().

in function calls there are some counters like "i" in the below
function. Is this stored in stack. If yes whether it will be deleted
on exiting from the function.

There is no such thing as a "stack" at the C language level. If you
want to know how a particular compiler operates, ask in a group that
supports that compiler. If you want to know how compilers in general
might work, try reading
With most of the implementations I use these days, the variable 'i'
will most likely be stored in a register and not in any kind of memory
at all.

is dynamic memory allocation needed for this purpose

Why do you think you need to know? Are you writing a compiler? If
'i' is stored in memory, it is stored where and how the writer(s) of
the particular compiler decided was the best way to do it, on the
processor for which the code is generated.

int listnum()
{
unsigned char i;
for(i=0;i>10;i++)
}

The C language does not specify or care where the memory comes from,
nor does a programmer writing a standard C program need to know.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[vivek]

vivek wrote:
Thanks. Typically which data are stored on the heap.
Data that can't be allocated statically or automatically. I'm not sure
what "typically" would be here.
[It also depends on what you mean by "the heap", since the Standard doesn't
talk about a heap; you can say that in C, "the heap" is the memory managed
by malloc/realloc/free, which leads to the unilluminating answer "data
allocated by malloc or realloc" ...]

On at least one system I work on, thread stacks are allocated from the
heap, so automatic data is also in heap space...

(fx:weasel) Fortunately, Standard C doesn't have threads.

Unfortunately, at least one C implementation handles stack overflow by
grabbing another block of memory from whatever-underlies-malloc and
linking it in to a chain of stack chunks, so (at least some) automatic
memory is mallocated.

Conclusion: It All Depends On Why It Matters.

Vivek, what difference do the answers make to what you do?

--
Chris "test-driven newsgroups" Dollin

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England- Hide quoted text -

- Show quoted text -

Chris,
Iam an embedded software professional for 3 years and iam migrating
from assembly language to C.(predominantly communication protocol
related)

Since in microcontrollers/processors memory is considered valuable,
iam trying to learn the better way of writing C code.

In assembly language, i can re-use the registers multiple times since
every thing we do on assembly is directly visible to the programmer.

Here in my system, there will be different threads like ADC interrupt,
Keypad interrupt, communication data received, LCD etc...

so when i switch between each thread i wanted to know where the data
is being stored and whether the memory used by automatic variables
inside functions or threads is being reused.

thanks,
vivek

 

[vivek]

C doesn't define stacks or heaps, nor are C compilers required to use
them.


When you call memory allocation functions malloc(), realloc(), or
calloc().


There is no such thing as a "stack" at the C language level. If you
want to know how a particular compiler operates, ask in a group that
supports that compiler. If you want to know how compilers in general
might work, try reading
With most of the implementations I use these days, the variable 'i'
will most likely be stored in a register and not in any kind of memory
at all.


Why do you think you need to know? Are you writing a compiler? If
'i' is stored in memory, it is stored where and how the writer(s) of
the particular compiler decided was the best way to do it, on the
processor for which the code is generated.


The C language does not specify or care where the memory comes from,
nor does a programmer writing a standard C program need to know.

--
Jack Klein
Home:http://JK-Technology.Com
FAQs for
comp.lang.chttp://c-faq.com/
comp.lang.c++http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

Jack,
Embedded software developers do need to know about where the data is
being stored for debugging and other purposes.

 

[James Kuyper]

I found this http://www.cs.uleth.ca/~holzmann/C/system/memorylayout.pdf
quite handy for general understanding.

My group is hiring multiple SW engineers and I've interviewed many
experienced SW engineers. Believe it or not, my impression have been
that 8 out 10 people don't know about this.

I can readily believe that. 8 out of 10 SW engineers probably never need
to know that kind of implementation-specific details; and if they do
need to know such details, it may be that they details they know are for
a system quite different from the one described in that document.

 

[CBFalconer]

.... snip sig, which vivek should have done earlier

Embedded software developers do need to know about where the data
is being stored for debugging and other purposes.

Then you should be looking in the documentation for your system.
It has nothing to do with the language.

 

[Podi]

I can readily believe that. 8 out of 10 SW engineers probably never need
to know that kind of implementation-specific details; and if they do
need to know such details, it may be that they details they know are for
a system quite different from the one described in that document.

Yes, that document is for a specific operating system. However, to my
knowledge, most *nix, Windows and some real-time operating systems
have a similar layout.

I meant to say that most SW engineers I've spoken with don't
understand the general concept of stack/heap/data when a process is
created. I have reviewed many other people's programs. And the ones
don't understand the memory layout usually write less efficient/
optimal programs. Some examples are: auto array variables with large
size, use of malloc when not necessary, initialized data with large
size arrays, etc.

vivek seems to be writing C programs for an embedded platform. My
suggestion is to read up on the OS/C reference manual for that
platform.

 

[Chris Torek]

I found this http://www.cs.uleth.ca/~holzmann/C/system/memorylayout.pdf
quite handy for general understanding.

I took a look at the PDF file. This is not bad, but it needs
a lot of commentary attached before it is used as a model for
general purposes.

In particular, it:

- assumes that the stack grows downward (though it does at least
document this); there are some machines where the stack grows
upward, or where "the stack" is kind of a meaningless term as
stack frames are allocated on what it labels the "heap";

- glosses over read-only data, which is quite common in modern
implementations;

- defines "bss" and "global" as equivalent, which (in my experience
at least) is rarely what most people seem to mean by "global";

- makes brash assumptions about the placement of shared segments,
if shared segments even exist, as well as text and data (some
MIPS-based Unix systems put data at 0x40000000, far away from
text, for instance);

- makes assumptions about parameter-passing and value-returning
mechanisms that are incorrect for many architectures (parameters
on MIPS, PowerPC, SPARC, etc., are passed primarily in registers)
and some situations (values of structure-valued functions are
only sometimes returned in registers); and

- unnecessarily implies that the OS lives in the same address
space as a "C process" (and for that matter, assumes that text
and data are in the same address space -- anyone remember split
I&D PDP-11 Unix?).

My group is hiring multiple SW engineers and I've interviewed many
experienced SW engineers. Believe it or not, my impression have been
that 8 out 10 people don't know about this.

In most cases, most do not *need* to know about it, although it is
probably good if they are aware of the issues involved. (These
include a lot of CPU-architecture-dependent details -- there are
reasons for doing things one way on Intel x86 and a completely
different way on PowerPC or MIPS, for instance).

 

[Flash Gordon]

Podi wrote, On 16/11/07 02:26:

I found this http://www.cs.uleth.ca/~holzmann/C/system/memorylayout.pdf
quite handy for general understanding.

I can see that as being good for understanding one particular
implementation, but it is very implementation specific.

My group is hiring multiple SW engineers and I've interviewed many
experienced SW engineers. Believe it or not, my impression have been
that 8 out 10 people don't know about this.

The last time I needed to know a memory layout in that detail it was
because I was working on an embedded system and I had to tell the linker
how to arrange the sections in memory. I have never needed that level of
knowledge when programming for a PC or server.

 

[Mark Bluemel]

Embedded software developers do need to know about where the data is
being stored for debugging and other purposes.

Vivek - please don't quote people's signatures, and consider editing
your quotations.

If you need to know where the data is stored, you'll have to find out
about the particular architecture and C implementation you're working
with. There isn't a general answer.

 

[Chris Dollin]

(Etiquette note: it's usual to snip signatures when you reply. The
is the thing after a line consisting only of "-- ".)

Iam an embedded software professional for 3 years and iam migrating
from assembly language to C.(predominantly communication protocol
related)

Since in microcontrollers/processors memory is considered valuable,
iam trying to learn the better way of writing C code.

This is a good reason to be concerned about your C implementation's
memory layout. But you have to realise that different implementations
may do different things. [I have no real experience writing for
embedded systems; there are those here who have and may be able to
point you to useful resources.] The first thing I think you should
consult is your C implementation's documentation: I would be surprised
if an embedded-C compiler didn't go into quite a lot of detail about
memory allocation, optimisation choices, non-Standard but very useful
(maybe essential) features of the implementation, etc. If you have
colleagues who have used that system, or you can find a forum or
mailing list for it, you can probably get more specific help.

[Historically-and-in-my-experience, this newsgroup is more concerned
with implementation-/in/dependant aspects of C programming, of which
there are quite enough to fill a newsgroup or seventeen; trying to
deal with all the embedded-implementation aspects would likely
reduce the group to spaghetti-and-razorblade soup. Also HAIME,
there have been debates, some heated, as to whether this is the
best choice ...]

so when i switch between each thread i wanted to know where the data
is being stored and whether the memory used by automatic variables
inside functions or threads is being reused.

That will be implementation-specific: Standard C doesn't even have
threads. For any sane thing I'd call a "thread", however, each
thread will have its own space for automatic variables -- they
won't interfere with each other.

A warning: when moving from one language (eg assembler) to another
(eg C) it's very easy to be obsessed with getting exactly the same
out of the new language as you did with the old. /You will have to
give up something/ in the transition; in return, you get something
else. One hopes what you get more than pays for what you give up,
but to get the benefits you have to be prepared to shift your ground.

[Don't expect idiomatic Spitbol programs to have the same structure as
Pascal programs: it doesn't work like that. At all. Fortunately, I
was young at the time, it was only coursework, and I learned a useful
lesson.]

 

[James Kuyper]

Podi wrote:
....

I meant to say that most SW engineers I've spoken with don't
understand the general concept of stack/heap/data when a process is
created. I have reviewed many other people's programs. And the ones
don't understand the memory layout usually write less efficient/
optimal programs. Some examples are: auto array variables with large
size, use of malloc when not necessary, initialized data with large
size arrays, etc.

Because the details of memory layout are implementation-specific, so is
any judgment about whether or not any of those features of the code make
it more or less efficient. In my last job, I remember being very
concerned about overflowing the stack, because it was very easy to do. I
would never create anything of any significant size automatically;
everything big was either static or dynamic. Our code could only be
successfully compiled by making use of some complicated special compiler
options relevant to memory management.

The first piece of code I was given to work on in my current job (and
it's still the one I update most frequently), routinely created
multi-megabyte arrays automatically. It's a memory hog, but it works on
every platform it needs to work on. Our organization's coding standards
explicitly provide a waiver of the 65535 byte limit for object sizes
that is mentioned in 5.2.4.1p1. It would be a major re-design task to
re-write that program so it could operate within that limit, and such
changes would incur a significant performance hit when running on the
machines we normally use.

YMMV - which is precisely my point.

 

[J. J. Farrell]

Embedded software developers do need to know about where the data is
being stored for debugging and other purposes.

I'm sure they do, but as Jack explained it varies dramatically between
processor/system architectures and between compilers. The C language
does not do it in any particular way; the compiler you are using does it
in some way which suits the architecture it is compiling for, and which
seemed like a good idea to the compiler implementer. The way your
compiler does it could be entirely different from the way another
compiler does it.

In general, different compilers targeting similar architectures (for
example, x86/32-bit/8-MB) are likely to do things much the same as one
another, though this isn't guaranteed. A compiler targeting a different
architecture (such as SPARC/64-bit/16-GB) is likely to do it
differently. Different compilers for hosted environments ("ordinary"
programs running under an Operating System) are likely to deal with the
same architecture in the same way because they are often constrained by
the Operating System (or by agreed interface standards - ABIs) to do
things in particular ways. Compilers for embedded environments have more
freedom.

To get specific answers useful to you, you'll need to study your
compiler and architecture documentation. It might also be useful to ask
in a group which discusses that compiler and architecture. There is no
general answer to your question for C as a language.

 

[Podi]

YMMV - which is precisely my point.

Digressing from pure C here...

For web application developers using C# or Java, I can accept that. I
used to work with a very senior developer who did not know about
endianess, not to mention stack/heap. What I didn't realize was that a
PC/Server programmer would not concern about such things, thus my
surprise. I forgot to mention that I was interviewing people for a
position that will involve with device driver programming in small
devices such as Window CE and embedded Linux.

Anyway, in my group's opinion, people understand the memory layout in
general usually produce higher quality programs.

Also, I don't understand why the multi-megabyte automatic variables
would be a memory hog instead of CPU hog. Your program needs the
amount of memory anyway for doing whatever it does. Wouldn't the large
arrays cause the OS to put it on the stack every time you enter the
function? Whereas if the arrays are allocated in the (uninitialized)
data section, you would have better performance? BTW, allocating large
arrays in the initialized data section would increase the file size of
the exectuable file (in most platforms: *nix and Windows).

So for example, we would like to work with developers who prefer to
pass pointer to a struct instead of the struct itself. Since every
function parameter is also copied on to the stack. The smaller the
stack each function requires, the better the performance of the over
all program.