[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