[BusyBox] choice for reserving buffers

[Larry Doolittle]

Vladimir says:

> In Larry Doolittle patch cp_mv must best usage BSS.

In some situations, I agree.  A problem that we observe
with BSS is that this answer doesn't "scale".  The BSS
space grows linearly (sort of) with the number of applets
included, while the actual memory needed is (sort of)
constant.  Both stack and malloc() approaches fix that
problem.

It would be nice to add BSS as an option to my list of
compile-time choices, but it can't happen cleanly,
due to the structure of c.  You would end up with

RESERVE_BB_BSS(buff,size);
foo_main() {
	RESERVE_BB_BUFFER(buff,size);
        ...
}

and one of the two macros would be defined as blank.
While possible, this is very ugly (IMHO), and increases
the chance for maintenance problems.

Here's one more strange possibility I can think of:
create a couple of BSS areas in global space, like
char bb_bss_reserve1[BUFSIZ+1];
char bb_bss_reserve2[BUFSIZ+1];
Then gunzip.c can:
	char *ifname=bb_bss_reserve1;
	char *ofname=bb_bss_reserve2;
and cp_mv.c can:
	pBaseDestName=bb_bss_reserve1;
This scales, certainly, but might invite another whole
class of problems.

I don't know what to suggest for the 0.49 release.
Version 0.48 put buffers in BSS.  The current CVS tree
puts them on the stack.  Both work fine for me, but
both my embedded targets have 32M of RAM and an MMU.

I think 0.49 should attempt to support the existing
customer base.  I'd like to hear from more of them
on this subject.

    - Larry