>Getting rid of printf means avoiding bb_error_msg(). >Which is everywhere. Currently, even in xmalloc.
It would not be useful to do this in BB, even in that other world, because the whole purpose of BB is to _share_ the bulkier junk. If you amortize all of printf over a dozen applets, all of which make significant use of it, then you've made a worthy trade. >Open-coding it without printf will quickly make code bigger >and harder to understand. Most of these tiny apps had a myprintf() function that I wrote, which took care of %d %s and %c. Nothing more, nor was anything more needed for most of these small apps. They only wanted to print an error-type message anyway, then exit. >That is one reason why things get bloated: programs >tend to fill all available storage. IIRC it's one of Murphy laws. Sure is, and helps ensure that there _are_ no more tiny bits of hardware. If there are no tools or infrastructure available to support a watch-battery-powered dingus, who's going to bother to develop one if they have to roll it _all_ from scratch? >Your files total to 243284 bytes (counting hardlinks >only once), and have 37 executables. It was a 30-second extraction from /bin, showing some of the more common ones, as well as the tiniest. Some of them, like ps, time, and ls, did _not_ get the treatment, and are in their bloaty size. That skews things a bit. This project was motivated by the desire to have a usable boot/rescue floppy. Fixed in size, the only way to get more onto it was to shrink things. Every time I wanted a new tool on the floppy I went byte-hunting. I almost always targeted the easiest ones first. (Sync was an early one!) Hard stuff, like ls, I never did get to. (I did a few other things like invoking a 512-byte block size on the floppy, and re-coding device files to not use more than the inode. [don't ask!] All these files are stripped, they have no symbol tables nor relocation entries. They're static, they don't need any of that stuff. Load, and jump. That's exec! Small, small, small... it was actually a lot of fun.) All that's readily available to me is the archive CD, so I can't show a find/ls from the boot floppy itself. It would probably take me days to resurrect the system itself, though it is in theory still possible. >I built busybox with 34 applets from that list >(I don't know what are chany, hd, and nkill). Chany was a micro-BB of chown/chmod/chgrp done by one of the guys. hd is a hex-od, modeled after the Xenix tool of that name. Nkill (named kill) seems to be called 'killall' these days. It should be noted that all of these _were_ the 'upstream' versions, for us. They weren't strippers in any sense, though in functionality they probably lay between BB and GNU somewhere. ># size busybox.shared busybox.static (w/ulibc) > text data bss dec hex filename > 55692 1394 8416 65502 ffde busybox.shared > 65477 1574 8440 75491 126e3 busybox.static Those are some pretty interesting numbers! The 10k difference for a static libc may well be compensated for by other means. Such as, removing entirely the dynamic linker from the 'rescue floppy', the shared libc itself, etc. The extra linkage pages required for a shared lib also factor into there, depending on what you're going for, when making a decision. If I'd thought of, or heard of, Busybox back then it might have caught my interest enough to try rolling it myself to see if I could save some space. I'd probably have called it 'vicky'. (Short for Victorinox.) -- Jim _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
