(part 6) Han from China answers your C questions

[Borked Pseudo Mailed]

Doubts about free()

[e-mail] said:

>
s1= (char *) malloc(sizeof(char) * 200)

This is where people here will tell you not to cast
the return from malloc(). They may even say that
malloc(200) suffices.

Question: How many CLC regulars does it take to miss
the lack of a semicolon at the end of a statement
while addressing more, um, pressing matters?

>In the above piece of code during execution malloc results in
allocating space physically in the RAM.

The regulars will tell you that RAM is off-topic on this newsgroup.
And with good reason. Under the provisions of ISO C, the above code
may result in a scaled rectangle called 's1' being drawn by a plotting
device and then read back in with an OCR device.

>Now after the first while loop
execution is complete free(s1) is called. At this point of time is
memory returned back to the OS or not always. I guess memory is just
marked as freed for future use by the same process.

Both options are possible.

>I have read that in some implementations of OS like some unix flavors
even after free() is executed memory is not released back to the
system. In the above piece of code is it the case that the memory is
never freed up at all in such implementations and remains tied up till
the process dies.

No. The freed memory may be placed on some kind of free list,
but on some Unix flavors, it's also possible that the memory allocator will,
subject to various compile-time and runtime options, trim the memory by
returning it back to the system. Some Unix flavors (using the word 'Unix' loosely,
of course) do this by calls to munmap(2) or sbrk(2). A negative argument to
sbrk(2) may result in memory being given back to the system.

>Is there any way to force freeing up the memory to the system back.

Not in ISO C. ISO C gives you a piece of scrap metal and a length of
rope and leaves it to you to make a kite.

Yours,
Han from China