busybox-1.3.0 and nonstd APIs, installment 2

[Rich Felker]

On Tue, Dec 19, 2006 at 11:20:34PM +0100, Denis Vlasenko wrote:
> > >The goal of the project is to be _small_.
> > >It means "use fdprintf() where it makes code smaller,
> > >and provide fdprintf() for libc's where it is missing"
> > 
> > I beg to disagree since i personally detest fdprintf and dprintf,
> > likewise.
> 
> Well, I do not love them, but I do not feel offended by them either.
> They are non-standard, yes. Is it a sin? No.

Yes, it is. I want to be able to continue using busybox on my libc,
which absolutely will not include functions not in SUSv3. I can add
ugly -D flags or local patches to work around this, or put the
functions in my libegacy.a, but where does it end? If I did this every
time some program insisted on using a brain-damaged glibc-ism, I'd
replicate the whole glibc monstrosity. There's really no legitimate
need to fdprintf.

> For example, out xasprintf is non-standard. Is it evil? NO.
> It is atrociously beautiful. Swiss army knife of string
> manipulation tool for C :)

Yes, it is evil. There's no reason you can't just call snprintf twice.
Putting allocation code in the printf core means that any program
which uses printf automatically pulls in the whole malloc bloat, which
is usually entirely unneeded in tiny static linked programs. There are
ways around it, yes, but it's a stupid hack. Just use the standard
functions in the standard way. Most of the time you know your buffer
size ahead of time anyway and don't even need to allocate a buffer
dynamically.

> I see it like this: we want to have a function which printf's
> to file descriptor, without need for explicit intermediate buffer.
> We can implement it ourself, like we did for xasprintf.
> But it happens so that glibc and uclibc alredy have one, so we use
> that.

My libc is 1/2 the size of uclibc and 1.1-50x the speed of glibc for a
reason. uclibc replicates way too much of the nastiness of glibc.

> If you really don't like it, please explain why it is evil.
> "Non-standard" isn't evil enough (at least for me).

One nonstandard function is not evil by itself. The problem is that
each program that uses nonstandard functionality wants a different
nonstandard function, so you end up requiring O(N) of them (rather
than just 1) for a complete system with N programs, if you allow such
dependencies on nonstandard functions to remain rather than fixing
them.

Rich