Re: [avr-libc-dev] malloc bug ?

[Joerg Wunsch]

As ken restivo wrote:

> SP doesn't seem to work.  Maybe __SP__ instead?

No such thing like __SP__.  There's __SP_L__ and __SP_H__, but only in
the generated assembler code, that's not usable within C code.

> Just manually changing STACK_POINTER to 0x5d seems to work just
> fine.

Sure, that's in effect what the _SFR_IO16() macro in <avr/sfr_defs.h>
is doing.

I also gave it a try, and my only project using dynamic memory still
works.  (It worked before, probably because subtracting
__malloc_margin's value of 32 from a small positive integer in the
EEPROM data register yielded a negative number, which was then cast to
a large unsigned number so it always assumed enough heap was
available. ;-)

Just for the sake of completeness (and since we've got CVS that can
keep track of these things), i've imported my original version of
malloc.c onto a vendor branch for comparision purposes.  This one was
still using port input operations to obtain the current stack pointer
value.

Since the bug was serious, i just committed a fix for it wrapping
the magic number 0x3D into _SFR_IO16().  We should agree on a better
solution wrt. not hard-coding register numbers in those files though.
-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/