malloc on tiny systems

[Jeff Johnston]

DJ Delorie wrote:
>> From the sounds of it, you would want to supply your own simplified 
>>malloc/free routines that concentrate on low storage overhead.
> 
> 
> I thought of that, and I have a handful of malloc implementations, but
> that's a baby squirrel I'd rather not play with.  Plus, the m32c
> family includes everything from the 1k r8c chips to multi-megabyte
> m32c chips.
> 
> I think I'm hoping to just avoid pulling in big things when the user
> doesn't do it themselves.  If I can blame the user for it, I'm ok with
> including it.
> 
> In this particular case, though, I had inadvertently left _REENT_SMALL
> undefined, and the configure tests couldn't even fit 'main(){}' into
> memory (r8c is the default).  That's when I noticed all the extra
> stuff.
> 
> 
>>Regarding your alternative solution of just using _exit(): that
>>solves the simplest case, but you still will likely run into code
>>that will call exit directly.
> 
> 
> If the user calls exit, I hope they know what they're doing.  They're
> either running on hardare, where exit() is deadly, or on the
> simulator, which has plenty of RAM.
> 
> Maybe part of my question is "can we ignore exit on embedded non-OS
> systems?"
> 

Ultimately you can define anything you want for your platform as long as 
you document it (e.g. "It is recommended you restrict the use of certain 
functions on the r8c, for example, the following routines will take up 
too much memory: ..."  I don't think it would be a terrible thing to 
have a special crt0 for the r8c that calls _exit instead of exit.  If 
you are intending on having a shared crt0, for all the board-types, that 
doesn't call exit, then I would definitely not recommend that.
> 

>>There is also what to do with atexit calls that you intend to
>>ignore.
> 
> 
> If you're running on real hardware, what to do with atexit calls is
> the *least* of your worries at that point ;-)