busybox-1.3.0 and nonstd APIs, installment 2

[Denis Vlasenko]

On Thursday 21 December 2006 23:38, Rich Felker wrote:
> 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,

I do _not_ insist_ on fdprintf _in _dietlibc_.

bbox can have its own fdprintf implementation for libc'es which
don't have one. I think this will make you _and_ me happy.

> > 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.

char buf[BIGNUM] disease. How much of BIGNUM do you need? 100?
256? 1024? How much of that 1024 will be wasted on average?
How much of buf[BIGNUM]s, mostly unused, will accumulate over
10-deep callchain?

Stack seems to be cheap, but it _is_ RAM nevertheless.
This should be important for embedded world.
--
vda