[PATCH] size reduction and clean up swaponoff.c

Rob Landley rob at landley.net
Sat Sep 17 18:51:55 UTC 2005


On Saturday 17 September 2005 12:46, Bernhard Fischer wrote:
> >If you're saying we should have one instance of these strings to save
> > space and can't trust compilers to get this right, fine.  But that's a
> > larger problem, there's a a lot of strings like that.  Putting each one
> > in its
>
> There are indeed more of these.
>
> >own .o file is _not_ a good solution here.
>
> hm, why not?

Because there's a minimum module size beneath which something's chopped up 
into so many pieces that the bug count goes through the roof and it's a 
serious pain to work with because you can't even see a single entire tree, 
let alone the forest.

http://www.catb.org/~esr/writings/taoup/html/ch04s01.html

For example, right now sed.c has 35 different symbols (functions and global 
variables).  Imagine I were to rewrite it to put every single one of those 
into its own .c file.  Now ask yourself: would it be more, or less 
maintainable?  It would be the same amount of code, but reading through it 
would require opening 35 files.  Trying to assemble a picture in your head of 
what it's doing would take _days_.

> >We need to work out some kind of mechanism for this, but having an
> >individual .c file and individual .o file for each string is just...  Ick.
>
> We do *not* have individual .c files for them. In another thread i
> proposed to put them into messages.c but you objected ¹). I locally have
> them now in libbb/static_strings.c but any suggestion for a more
> appropriate name or place is welcome. It's really a minor detail, imho,
> but i want to resolve it sooner rather than later.

Okay, you have individual .o files but not individual .c files.  What exactly 
are you doing?

> ¹) later in said thread, you admitted that you "tend to have a tropism for
> _fewer_ files", but ok.

I think there's an optimum .c file size somewhere in the neighborhood of 
500-3000 lines.  Much smaller than that and you've added a gratuitous jigsaw 
puzzle element to your programming.  Much bigger than that and it gets 
unwieldy.

Rob



More information about the busybox mailing list