[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: busybox-1.3.0 and nonstd APIs, installment 2
From:       Rich Felker <dalias () aerifal ! cx>
Date:       2006-12-22 1:35:26
Message-ID: 20061222013525.GA29099 () brightrain ! aerifal ! cx
[Download RAW message or body]

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.

Rich
_______________________________________________
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]