buffer allocation/destruction

Rob Landley rob at landley.net
Tue Aug 30 01:06:44 UTC 2005

On Monday 29 August 2005 17:35, Bernhard Fischer wrote:
> Hi,
> I'm in the process of making more applets peruse RESERVE_CONFIG_BUFFER.
> I'm not sure how to deal with the destruction of buffer in the case of

There's a more fundamental problem.

bb_perror_msg_and_die() and friends call exit(), and our code is littered with 
calls to that.  Any attempt at making FEATURE_CLEANUP comprehensive (which is 
needed to use setjmp/longjmp in place of fork/exit) has to deal with that 
mess, where our exit code that does the cleanup simply never gets called.

There's a couple ways we can do this.  Our FEATURE_CLEANUP code can register 
an atexit() function (like sed has been doing since before I first touched 
it).  We can also have special allocation functions that create a linked list 
of memory we've allocated, which can be freed with a single call that 
traverses the list (possibly with a "since" pointer so it only frees 
sufficiently recent allocations).  Both are pretty ugly, and neither is quite 
compatible with the "free it as we no longer need it" method we've been 

This is major surgery.  Dealing with CONFIG_BUFFER, FEATURE_CLEANUP, and 
FORK_LONGJMP (or whatever it's going to be called) is actually one big 
tangled mess that probably has to be done all at once.

Now on the bright side, if we convert more stuff to allocating on the stack, 
then the clean_up case gets easier and easier.  And allocating stuff on the 
stack saves us the overhead of a function call, thus making the code smaller.  
But I'm under the impression there are downsides to this; broken boxes that 
have very limited stack space. 

Erik would know the details...?


More information about the busybox mailing list