I have a trival question that is confusing me.  I am trying to
determine where/what happens to memory when using calloc() and
malloc().  It seems that all the requested memory is calloc'd but not
all is free'd when running this program.

This is what I am seeing inbetween the gets():

When list is created (63% mem):
--------------------------------
cdaniel    212 12.5 63.6 241564 81520  p0 S    16:09   0:01 ./tmp

When list is free'd (35% mem):
-----------------------------
cdaniel    212  3.5 35.3 132628 45216  p0 S    16:09   0:01 ./tmp

Where is the memory going?  Of course it's gone when the program
terminates.   At least I think :)  Any help is appreciated.

Below is the sample program written specifically to test memory under
Linux 2.0.12 on a P133 w/128MB.
#include <stdlib.h>
#include <stdio.h>
#include <malloc.h>

struct temp_struct {
  char dumb[8192];  
  struct temp_struct *next;

struct temp_struct *newp, *hp, *ll = NULL;

void main(void)
{
  int i;
  char input[2];

  ll = (struct temp_struct *) calloc(1, sizeof(struct temp_struct));
  hp = ll;

  printf("\r\nPress Enter to create link list...");
  gets(input);
  ll = hp;
  i = 0;  
  while(ll) {
    i++;
    ll = hp->next;
    free(hp);
    hp = ll;
  }
  printf("\r\nCalled free() %d times...", i);
  gets(input);

free() is not required to return any memory to the operating system, the
free'd memory might still belong to your program, available for the the
next malloc/calloc/realloc request.

One interpretation of the standard is that free() is not even allowed to
return any memory to the operating system.

Dan
--
Dan Pop
CERN, IT Division

Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

composed the following epistle:

???

That sounds a bit odd, can you elaborate ?

I can see why one may want to keep the memory tied to the program, given
an OS that allows local heaps of memory to be handled with less overhead
than if these allocations should request the memory from the system heap,
but to forbid free() to return the memory, sounds downright dumb to me.

I'm not an expert C-programmer, infact I've just learned the language,
and not very familiar with the tricks in C. I'm writing a calculator,
somewhat like the Texas Instrument Ti-8x series, but without the
graphics. If anyone has any experience in this, is interested in my
project, or is indecently good lookin, get in touch with me :)

I have a few questions though, which should be fairly simple.

1. I'd like some kind of interactivity in my program, i.e, when the user
presses arrow-up he should get the last entered string, like doskey in
dos, or zsh in unix, or whatever. Is there any good way of doing this
without using ncurses? (My program is 100% unix-based)
I'm not scared of ioctl, and something tells me I need to use this here,
but if anyone has written a "small" interactive program that uses this
feature, can I plz have a look at it? ( I don't consider zsh a small
program :) )

2. There is a finite precision in long double, and how do I avoid things
like this?

Eval: 40000040000000001215128101659198867111936.000000

I'm not looking for arbitrary precision, I don't have enough time to
rewrite my entire program, but I want the answer to be like,
40000000000000e18. Hmm.. I guess what I'm looking for is a way of
_knowing_ how many digits are correct. There must be some text about
this on the net.

3. I can't come up with a good name for my program, EvalYouAte stinkz...
Ai-85 is a little too{*filter*}y, any suggestions?

Thanx in advance,

--
-----BEGIN GEEK CODE BLOCK-----



-----END GEEK CODE BLOCK-------

Basically both functions do exactly the same. The only difference is
that "calloc" has a sighlty different prototype and initialises all
bytes to 0.

"void main" is not legal C code ! It MUST be "int main".

You should use "malloc()" except for when your *really* need the zero
initialisation. This is only a style and performance issue. It does
not pertain to your problem.
Don't forget to check the value returned by "malloc" for NULL !

AFAICS your program calls "malloc()" and free once with the correct
arguments.

The answer to your problem is in the FAQ (which you should have read
before posting):
  7.25:   I have a program which mallocs and later frees a lot of
memory,
          but memory usage (as reported by ps) doesn't seem to go back
          down.

  A:      Most implementations of malloc/free do not return freed memory
          to the operating system (if there is one), but merely make it
          available for future malloc() calls within the same program.

The FAQ has a lot more to offer on the subject of dynamic memory.
Don't hesitate to read it ASAP.

You can get the FAQ at http://www.eskimo.com/~scs/C-faq/top.html or
at ftp://rtfm.mit.edu/pub/usenet/comp.lang.c/C-FAQ-list and it gets
posted to this newsgroup and to news.answers regularly (at the
beginning of each month).

Stephan

The words describing what "free" does indicate that the memory "is
available for further allocation" which seems to indicate that in

   char* p = malloc (10000);
   if (p != NULL) {
      free (p);
      p = malloc (10000);
   }

the second call to malloc might be guaranteed to be successful. If the
memory is returned to the system, there is a good chance that the memory
is grabbed by some other program that was waiting for memory to become
available.

I am not saying this is the correct interpretation of the standard.

-- For email responses, please remove the last emm from my address.

Can you explain that interpretation?  
I never expect that free() will return memory to the OS,
but I have assumed that this is done for simple efficiency reasons.

Note that some implementations (e.g. Gcos-8 small model), do supply
a separate function that can be called after free() to return what
memory is possible to the operating system.

The wording of the standard is the space freed by free() is "made available
for further allocation". If this memory is returned to the OS is it still
available for further allocation by that program?

--
-----------------------------------------


-----------------------------------------