Some advice about references on memory management in C

[Rafael Charnovscki]

I can comprehend the basics of that subject (pointers, memory
allocation, heap, stack etc), but I am interested to have
references with more details. I have some C/C++ books
and lots of URLs "bookmarked", but all of them don't go too
far on memory management as I would like. One of my main issues
is whether function "main" and its local variables are allocated
on the stack area as other functions.

Does anybody recommend a good book or site with a good text
on memory management in C/C++?

In comp.lang.c++ someone recommended "C++ Pointers and Dynamic
Memory Management", by Michael C. Daconta. Is it good?

Does anybody know the book "Memory as a programming
concept in C and C++" (Cambridge Press - link below)?
(http://titles.cambridge.org/catalogue.asp?isbn=0521520436)
There are some resources here
"http://www.cas.mcmaster.ca/~franek/books.html".
However, I'd like to have some advice about the whole book.

Regards and TIA,
Rafael Charnovscki

 

[dandelion]

I can comprehend the basics of that subject (pointers, memory
allocation, heap, stack etc), but I am interested to have
references with more details. I have some C/C++ books
and lots of URLs "bookmarked", but all of them don't go too
far on memory management as I would like. One of my main issues
is whether function "main" and its local variables are allocated
on the stack area as other functions.

It's really not that hard.

As a rule of thumb:

All local variables are located on stack, as are parameters to functions,
global variables are located in the .data (or equivalent)segment and
everything you alloc() on the heap.

The .data segment (that's what they call it in UNIX, forgive me) is loaded
with the rest of your program (memory is allocated by your OS) so you can
'initialize' that data by just assigning a value to it.

int global_a = 42;

void foobar(int parameter_b)
{
void* local_c;

local_c = malloc(0x0100)

...
}

then global_a would be in your .data segment, parameter_b and local_c would
be on stack and *local_c would be in the heap.

I cannot give any advice on books, but I could reccomend a decent debugger
and a simple sample program so you can check for yourself.

Regards,

dandelion

 

[Michael Mair]

Hi there,

It's really not that hard.

As a rule of thumb:

All local variables are located on stack, as are parameters to functions,
global variables are located in the .data (or equivalent)segment and
everything you alloc() on the heap.

The .data segment (that's what they call it in UNIX, forgive me) is loaded
with the rest of your program (memory is allocated by your OS) so you can
'initialize' that data by just assigning a value to it.

int global_a = 42;

void foobar(int parameter_b)
{
void* local_c;

local_c = malloc(0x0100)

...
}

then global_a would be in your .data segment, parameter_b and local_c would
be on stack and *local_c would be in the heap.

I cannot give any advice on books, but I could reccomend a decent debugger
and a simple sample program so you can check for yourself.

Note, however, that the C standard does not say anything about heap or
stack, let alone .data. That is, one cannot rely on things being like
described, even though the description gives you a good idea of
how things are done on a specific platform.

Another book which can give you a good idea of how addresses are mapped
and so on, is "Linkers and Loaders". I do not have the link right
now, but there is an alpha version of the book out there for free
(legally).

Once again: This information does not hold for all standard compliant
C environments. If you have a certain system and a certain compiler
in mind, you may want to ask in the respective newsgroups.


Cheers,
Michael

 

[John Bode]

I can comprehend the basics of that subject (pointers, memory
allocation, heap, stack etc), but I am interested to have
references with more details. I have some C/C++ books
and lots of URLs "bookmarked", but all of them don't go too
far on memory management as I would like. One of my main issues
is whether function "main" and its local variables are allocated
on the stack area as other functions.

The problem is that not all machines are stack-based. A good number
of them are, but the C language doesn't require it.

AFAIK, main() is treated like any other function as far as how it's
data is managed, but the details may vary based on the platform. You
might be better off asking this kind of question in a newsgroup
devoted to your particular architecture.

 

[Jack Klein]

It's really not that hard.

As a rule of thumb:

All local variables are located on stack, as are parameters to functions,

....unless of course you are using an efficient compiler for a modern
processor architecture, and then at least some of the parameters and
local variables are entirely in registers. Possibly all of them,
depending on how many there are.

global variables are located in the .data (or equivalent)segment and
everything you alloc() on the heap.

....unless of course they are default initialized, in which case they
are more likely to be in another section.

The .data segment (that's what they call it in UNIX, forgive me) is loaded
with the rest of your program (memory is allocated by your OS) so you can
'initialize' that data by just assigning a value to it.

You seem to have forgotten about file scope and block scope values
with static storage duration. Not to mention string literals and
constant objects.

The true answer is that there is no rule of the thumb. If it made
sense for there to be a rule of the thumb, it would be in the C
standard, which it most certainly is not.

The only answer to a question like this, from a language stand point,
is to direct the OP to a group that specialized in the particular
OS/compiler combination that interests him. It may be quite a bit
different from others, and from the model you are familiar with.

 

[Richard Tobin]

One of my main issues
is whether function "main" and its local variables are allocated
on the stack area as other functions.

In typical implementations on general-purpose computers, the function
main() is called in the usual way from some other function, which also
handles calling exit() if main() returns.

-- Richard

 

[dandelion]

functions,

...unless of course you are using an efficient compiler for a modern
processor architecture, and then at least some of the parameters and
local variables are entirely in registers. Possibly all of them,
depending on how many there are.


...unless of course they are default initialized, in which case they
are more likely to be in another section.

Hence "(or equivalent)".

You seem to have forgotten about file scope and block scope values
with static storage duration. Not to mention string literals and
constant objects.

Ummm...

Scoping (in this case and to my knowledge) is dermined by the kind of record
generated by the compiler and is ultimately delt with by the linker.

You seem to have forgotten the little "As a rule of thumb" I put in front of
my remarks.

The true answer is that there is no rule of the thumb.

Not one that is generally valid or refelcts exactly what the standard says,
but rules of thumb (i.e. inaxact, but workable) do exist. The above works
well wen explaining stuff to (relative) newbies.

If it made
sense for there to be a rule of the thumb, it would be in the C
standard, which it most certainly is not.

Standards and "rules of thumb" are two extremey different things, one seeks
to define exactly and exhaustively, the other seeks to give general rules,
which are easy to work with, eventhough they are not always and exactly
true.

I would be very disappointed if standards contained "rules of thumb".
Standards are intended for those who write compilers, rules of thumb for
newbies and regular users who want a rough idea without worrying about the
exact details.

The only answer to a question like this, from a language stand point,
is to direct the OP to a group that specialized in the particular
OS/compiler combination that interests him.

Perhaps. In that case you can just sit back, delegate all practical
questions to some other n.g. and lock yourself in an ivory tower of language
abstractions and formulations in The Standard, I presume.

I can see how that would be attractive. I, personally, prefer to give
answers (to specific questions) people can work with, eventhough the details
may be less than exact.

It may be quite a bit different from others, and from the model you are

familiar with.

That's quite a lot of models, platforms and languages and dialects, from
assemby to Prolog, from Sun Supersparc and PowerPC to (refurbished) 68000,
Z80, AVR, PIC and 68HC11.

Regards,

dandelion.

 

[dandelion]

The problem is that not all machines are stack-based. A good number
of them are, but the C language doesn't require it.

Noted. However, I am still pondering the architecture in use today which
does not. I know about IBM 360, but those are ancient (in computer terms).

 

[Flash Gordon]

Noted. However, I am still pondering the architecture in use today
which does not. I know about IBM 360, but those are ancient (in
computer terms).

Ancient in computer terms does *not* mean that it is no longer in use. I
don't know about the IBM 360 or other machines that are not stack based,
but I do know (from personal involvement) of systems based on the Z80
processor programmed in assembler being updated and sold to new a new
large customer in the late 90s and of another customer who signed for an
option of 20 years of support on another variation. So if we will have
Z80 based systems with an expected end of life after 2015 it is possible
you could find any system since the C89 standard still in use and
undergoing active maintenance. So it is important when learning that one
learns which assumptions cannot be made.

 

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Noted. However, I am still pondering the architecture in use today which
does not. I know about IBM 360, but those are ancient (in computer terms).

System 360 /is/ ancient, but S/390 is only /old/, and zSeries is practically a
baby. *But*, you can compile and run a C program on each of these IBM
S/360-compatable processors without problems. No stack necessary.

And, the architecture may be ancient, but we still use it for a large (> 50%)
of big business computing. Your bank, your hospital, and your local government
all use these machine.


- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBauyWagVFX4UWr64RAvVgAKDUIN39+EG/9eqaHtA0gbYN0FuAOwCggoBu
m+uQKwxBic+CvwuYPhkGV58=
=MmS+
-----END PGP SIGNATURE-----