malloc on tiny systems

[Schwarz, Konrad]

The C89 standard limits the number of call required to be supported by
atexit() to some small number (8?).  The free() could be sidestepped if
atexit() where modified (resp. a custom atexit() developed) to actually
enforce this limit.

However, perhaps it would be possible for _call_exit_procs() to simply
omit the call to free().  If a process is about to exit to the operating
system (or whatever), what use is there in freeing memory?  The
operating system will deallocate all memory segments anyhow; a "naked"
system can do whatever it likes, such as reinitializing pointers used to
implement sbrk().

I would argue against removing exit() since it provides a standard way
of returning to the system-specific start-up code.  This start-up code
can then do system-specific things, e.g., cause a reboot to occur, loop
back to the beginning for a "warm boot", emit a diagnostic message, or
whatever.

Regards,

Konrad
> -----Original Message-----
> From: newlib-owner@sourceware.org 
> [mailto:newlib-owner@sourceware.org] On Behalf Of Jeff Johnston
> Sent: Wednesday, December 14, 2005 2:19 AM
> To: DJ Delorie
> Cc: newlib@sources.redhat.com
> Subject: Re: malloc on tiny systems
> 
> 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 ;-)
> 
>