As Boyapati, Anitha wrote: > This means when a user requests say for x bytes from heap, he will > get x+2 bytes.
Yes, but keep in mind that this will *only* happen if the request is satisfied from a freelist entry that was exactly x+2 bytes long (as such an entry could not be split into an actual part to return, and a remainder to keep in the freelist). > Suppose a user's application does a hack on the memory returned to > verify the exact size, would not this be a problem? What "hack" do you have in mind? The user is requesting a piece of memory x bytes long. The only grant that is implied by returning a non-NULL pointer is that this points to a memory area that has /at least/ x bytes space. For example, in environments where RAM consumption is not such a big problem as for microcontrollers, it is quite common to round up each request to the next power of two for efficiency reasons (at least for small requests). For the pointer returned, the user must /never/ write below ptr[0] or above ptr[x-1], so it could not possibly detect how large the memory chunk returned actually is. > Or he may want > write his own free(). He is not allowed to do this (the C standards explicitly forbids that an application overrides a library implementation), and this would not work in almost /any/ C environment, because the way free() must be implemented is completely tied to the implementation of malloc() itself. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev