malloc on tiny systems

Schwarz, Konrad
Wed Dec 14 18:03:00 GMT 2005

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


> -----Original Message-----
> From: 
> [] On Behalf Of Jeff Johnston
> Sent: Wednesday, December 14, 2005 2:19 AM
> To: DJ Delorie
> Cc:
> 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 
> > 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 ;-)

More information about the Newlib mailing list