bb_*printf functions: are they useful?

[Rob Landley]

On Tuesday 19 September 2006 12:53 pm, Denis Vlasenko wrote:
> Hi Rich, busyboxers,
> 
> Do we really need libbb/printf.c?

I asked this on irc, and Manuel Nova answered:

http://purl.rikers.org/%23uclibc/20060630.html.gz
http://purl.rikers.org/%23uclibc/20060701.html.gz

Discussion of bb_printf starts at the end of the first day and continues past 
midnight into the second day.

> Any applet which primary function is to process stream data
> (sed, awk, dd, cut...) is probably already explicitly checks
> for that and exit with nonzero.

Not all of 'em, and our test cases don't check for it.  (It's on my to-do 
list.)  Note also that close() can return an error and set errno on nfs 
(which a pathologically mis-designed system and I'm not sure I care, but the 
fact remains it can.  Although if you don't call fsync() first, it doesn't 
really matter...).

> Then most likely do not use 
> (or "should not use"?) printf-like functions for output,
> at the very least because it is a bit slow to push
> megabytes thru stdio.

I've held off on worrying about it until I tackle the whole problem of 
upgrading the test suite to test for -EFULL (which requires mounting 
something like a size-limited tempfs, which would require root access).  The 
infrastructure's there (for mount.testroot) but it's incredibly awkward and 
I'd like to give it the option to use QEMU as well as UML, and probably write 
up better documentation on how to use it (see "awkward").

I don't want to use real root access for this because if the sucker aborts 
halfway you may have to reboot to clean up the leftover temporary mounts and 
so on.  That's on top of potentially eating your data. :)

> printf functions, I think, are commonly used by applets
> for error messages to stderr and by applets which produce
> human-readable output (IOW: not typically consumed by pipe).
> Things like hdparm, fsck, ipcs.
> 
> What we are trying to achieve by using special versions
> of printf in e.g. ipcs.c?

Setting xfeof().  Which is odd, because presumably if we care we should just 
_abort_, but I didn't write it and I haven't audited it.  I suspect 
xfprintf() would be a better name for the "aborts" version.  And wouldn't 
require games to set the error flag...

> How it was supposed to work, anyway? Like this?
> 
> applet_main()
> {
>         ....
>         return ferror(stdout);
> }

Possibly.  Dunno.

> We don't do that now.

Agreed.

> IOW: I grepped thru the tree. I think bb_*printf is
> almost never used for stream processing. Can I remove it?

Ask Manuel Nova, he put it in there.  Even though he's wandered away (he's one 
of Erik's lieutenants: when Erik focuses on uClibc he followed) he's still 
highly clueful.  Ask him what he had in mind.

Rob
-- 
Never bet against the cheap plastic solution.