busybox-1.3.0 and nonstd APIs, installment 2
dalias at aerifal.cx
Fri Dec 22 01:35:26 UTC 2006
On Fri, Dec 22, 2006 at 01:37:39AM +0100, Denis Vlasenko wrote:
> > > 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.
Yes, it does! :)
> > 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.
*nod* Certainly this is a problem too. I don't mind using asprintf
family of functions as long as there's a fallback to calling snprintf
twice if they're not available. I think that's reasonable.
More information about the busybox