[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[avr-libc-dev] Malloc implementation in avr
From: |
Boyapati, Anitha |
Subject: |
[avr-libc-dev] Malloc implementation in avr |
Date: |
Mon, 14 Sep 2009 14:20:10 +0200 |
Hi,
I have a question w.r.t malloc implementation in AVR. Malloc pages from
avr-libc user manual (http://www.nongnu.org/avr-libc/user-manual/malloc.html):
Excerpt -
"When allocating memory, first the freelist is walked to see if it could
satisfy the request. If there's a chunk available on the freelist that will fit
the request exactly, it will be taken, disconnected from the freelist, and
returned to the caller. If no exact match could be found, the closest match
that would just satisfy the request will be used. The chunk will normally be
split up into one to be returned to the caller, and another (smaller) one that
will remain on the freelist. In case this chunk was only up to two bytes larger
than the request, the request will simply be altered internally to also account
for these additional bytes since no separate freelist entry could be split off
in that case. "
I am trying to understand the rationale behind the last case. The corresponding
source file malloc.c has the following code (line 112) in for malloc(size_t
len) -
/*
* Step 2: If we found a chunk on the freelist that would fit
* (but was too large), look it up again and use it, since it
* is our closest match now. Since the freelist entry needs
* to be split into two entries then, watch out that the
* difference between the requested size and the size of the
* chunk found is large enough for another freelist entry; if
* not, just enlarge the request size to what we have found,
* and use the entire chunk.
*/
if (s) {
if (s - len < sizeof(struct __freelist))
len = s;
This means when a user requests say for x bytes from heap, he will get x+2
bytes. Suppose a user's application does a hack on the memory returned to
verify the exact size, would not this be a problem? Or he may want write his
own free(). Although the probability of such a case is low, it still appears
as a limitation to me(I think a testcase might be difficult for such a case)
Regards
Anitha
- [avr-libc-dev] Malloc implementation in avr,
Boyapati, Anitha <=