Doubts about free()
pushpakul...@gm ail.com said:
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?
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.
Both options are possible.
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.
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
pushpakul...@gm ail.com said:
>
s1= (char *) malloc(sizeof(c har) * 200)
s1= (char *) malloc(sizeof(c har) * 200)
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.
>allocating space physically in the RAM.
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.
>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.
>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.
>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.
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.
rope and leaves it to you to make a kite.
Yours,
Han from China