[avr-libc-dev] Fix for bug #2143 (malloc() wraps around top of extRAM)

[Joerg Wunsch]

Hi all,

and sorry for the x-post.  I'm (finally) about to fix bug #2143

https://savannah.nongnu.org/bugs/?func=detailitem&item_id=2143

Basically, the issue is that malloc() doesn't properly detect the top
of external RAM iff the top of heap is at the 64 KB boundary, because
of an overflow in the internal calculation that used to use 16-bit
(default) integers.  The suggested fix is at

https://savannah.nongnu.org/patch/?func=detailitem&item_id=2159

which is technically correct, it fully fixes the problem.  However, it
unfortunately also adds another 44 bytes to the code (for the avr5
architecture, avr3 might be even worse), or IOW about an additional 10 %.
Now, while malloc() will behave correctly, this only serves people who
actually intend to use the heap up to the 64 KB barrier -- anyone else
is served as well with the current implementation.

So I'm now polling for opinions whether to

1)  always use the corrected implementation, unconditionally, since
    it is the technically correct one

2)  also offer the current implementation as a linker option, in the
    same spirit as the various printf() options (I'd like to make the
    correct implementation the default than, and offer this smaller
    one as an alternative)

I just have no clues about whether people do like this sort of
link-time options at all.  Technically, it's not a big issue to offer
them, it requires a few hacks in the Makefile, but that's not too
difficult.

If we decide for 2), I could also make the ancient malloc()
implementation another link-time selectable option.  This
implementation was prone to memory fragmentation issues, but it's been
a lot smaller, and I see many people complain about the size issue of
malloc() (and thus about stdio in general since it currently always
uses malloc()).  We could probably even add an option #4 for an
allocator that just returns a piece of memory which is never intented
to be free()ed again.  Ought to be enough to get stdio going, and
that's probably darn small code.

Btw., I've also got a realloc() implementation almost ready to commit
(I've once needed that for a test-case with a lex/yacc parser), but
since this will cause a major restructuring of the code (variables
that have currently static scope inside malloc.c need to become
library-public), I'd like to resolve bug #2143 first because that fix
itself should definately also be merged into the 1.x branch.

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/