avr-libc-dev
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]