[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] Malloc implementation in avr
From: |
Joerg Wunsch |
Subject: |
Re: [avr-libc-dev] Malloc implementation in avr |
Date: |
Mon, 14 Sep 2009 14:44:09 +0200 |
User-agent: |
Mutt/1.5.11 |
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. ;-)