[PATCH] attempt to reduce size in readlink

Rob Landley rob at landley.net
Fri Sep 16 16:14:16 UTC 2005


On Friday 16 September 2005 06:45, Tito wrote:
> Hi,
> this is just a proposal to reduce size of readlink.
> I personally don't like this coding style so much,
> so Rob it is up to you if you want to apply it.
> Size reduction is:
>    text    data     bss     dec     hex filename
>      98       0       0      98      62 debianutils/readlink.o.orig_with_f
>      88       0       0      88      58 debianutils/readlink.o.new_with_f
>
>      76       0       0      76      4c debianutils/readlink.o.orig_no_f
>      46       0       0      46      2e debianutils/readlink.o.new_no_f
>
> Let me know what you think about it...
>
> Ciao,
> Tito

You shouldn't need an #ifdef around #include files.  Does that really save 
space?

Hmmm...  Eliminating all the option parsing code when there are no options is 
indeed cool, but you're right that it seems like there should be a better 
way...

Off the top of my head I can figure out how to have a single code path 
probably evaluate to the same code (with a compiler that can do constant 
propogation, anyway, and yes I'm thinking "ulong opt = ENABLE ? getopt() : 
0") for everything except optind.  That side-effect of bb_getopt_ulflags() is 
a bit tough to optimize away except via brute force like this patch does...

Lemme ruminate on this one a bit.  (By which I mean "lunchtime".)

P.S.  Why does the _big_ version get smaller?  I checked and made sure that 
ENABLE ? "f" : "" did _not_ include both strings.  On gcc 3.3.5, anyway...  
What compiler version are you using?  (It would be nice to nail down which 
gcc versions are broken about including constant strings that the calls to 
are optimized out...)

Rob



More information about the busybox mailing list