[BusyBox] #define -> static const int (last call)

[Mark Whitley]

Per Erik's "last call for patches", here is the latest '#define -> static
const int' patch. This got pushed onto the back burner for awhile, but it's
back, and ready to go in.

Some responses to various comments / critiques that have been voiced:



On Static Buffer Elimination
----------------------------

First, some background to put this discussion in context: Static buffers look
like this in code:

	/* in a .c file outside any functions */
	static char *buffer[BUFSIZ]; /* happily used by any function in this file,
	                                but ick! big! */

The problem with these is that any time any busybox app is run, you pay a
memory penalty for this buffer, even if the applet that uses said buffer is
not run. Hence, I undertook to eliminate them, thusly:

	static char *buffer
	...
	other_func()
	{
		strcpy(buffer, lotsa_chars); /* happily uses global *buffer */
	...
	foo_main()
	{
		buffer = xmalloc(sizeof(char)*BUFSIZ);
	...

However, Matt Kraai noted that, in my efforts to eliminate big, static
buffers, I was trading bss segment for text segment with such code. Rather
than mallocing the buffers (and thus growing the text size), I can instead
declare these buffers on the stack in the *_main() function and make them
available globally by assigning them to a global pointer thusly:

	static char *pbuffer
	...
	other_func()
	{
		strcpy(pbuffer, lotsa_chars); /* happily uses global *pbuffer */
	...
	foo_main()
	{
		char *buffer[BUFSIZ]; /* declared locally, on stack */
		pbuffer = buffer;     /* but available globally */
	...

Thus:
	- global static buffers are eliminated
	- we don't grow the text segment as much because no malloc() call is made;
	  memory is automatically allocated on the stack when execution context
	  enters the function. (We still grow text a little bit because of the
	  assignment, but that's cheap compared to a function call.)
	- the buffer is still available globally via the pointer

Thanks, Matt. I plan on putting notes to this effect in style-guide.txt so
this kernel of wisdom is available to future generations of busyboxers...



On *Blech* Enums Instead of #defines
------------------------------------

Larry Doolittle took umberage at the fact that I did this in cmdedit.c:

	-#define ESC    27
	-#define DEL    127
	+enum {
	+   ESC = 27,
	+   DEL = 127,
	+};

Larry, allow me to defend my actions here: I would have loved to use a 'static
const int' declaration for these instead of an enum, but gcc barfs chunks when
you try to do that. Why gcc treats enum'ed variables as first-class citizens
and const'ed variables as second-class citizens is anybody's guess. I consider
it a bug, but to work around the damage, I had to use an enum. Not my choice,
my hand was forced. The good news is, this approach assigns things fine and
you can see the values in the debugger.



Other Madness
-------------

gcc barfs when you do:

	static const int foo = 42;
	static int bar = foo; /* gcc err: initializer element is not constant */

Yep, that's right folks, gcc claims that a 'const' variable used as an
initializer is _not_constant_. I consider this to be another bug. To work
around this, I did:

	static const int foo = 42;
	static int bar; /* intentionally uninitialized */

	int first_func_to_use_bar()
	{
		bar = foo; /* initialized here */
	...

I need to remember to take that up with the gcc maintainers one of these days
RSN.



Final Notes
-----------

Here's the latest size comparison:

$ size busybox-orig 
   text    data     bss     dec     hex filename
 237501   29660   65884  333045   514f5 busybox-orig
$ size busybox-const 
   text    data     bss     dec     hex filename
 238157   29692   39964  307813   4b265 busybox-const
                  ^^^^^
                   yay!

To restate some previous notes: I didn't touch gzip.c or mkfs_minix.c because
they scare me and need more work than I want to do right now.

Oh yeah, the "ready to commit" diff can be accessed at:

	http://busybox.net/~markw/constify.diff

Anyone interested can give it a look-see and offer any comments / critique /
feedback / lucrative movie deals / etc.



Mark Whitley
markw at lineo.com