busybox Digest, Vol 13, Issue 57

[Rich Felker]

On Mon, Aug 28, 2006 at 10:35:10PM +0200, Bernhard Fischer wrote:
> On Mon, Aug 28, 2006 at 04:27:18PM -0400, Rob Landley wrote:
> >On Monday 28 August 2006 12:58 pm, Bernhard Fischer wrote:
> 
> >> Personally, i'd be reluctant to accept *any* re-impl of e.g. that
> >> functionality if it does not impose a size-improvement.
> >
> >How about "not using getopt from libc at all"?  That's the real motivation.  
> >We're now wrapping getopt deeply enough that it's easier to just do it 
> >ourselves (and not permute our arguments either).
> 
> In the usual few setups that i happen to know, libc already has to
> implement getopt for use by non-busybox applications installed along
> busybox. So, as long as a forked getopt() impl is optional and -- if
> turned off in busybox -- does not impose any size increase and is *at*
> *most* size-neutral if we provide an in-busybox impl to other applets
> (via e.g. making busybox PIE, have a patch for doing that lingering
> somewhere), then it's ok with me.
> 
> If it adds to the size either way, then i will not use it, fwiw

You misunderstand. I suspect Rob (or other BB developers) can write a
command line parser that's about the same size or even smaller than
the current wrapper code that calls getopt. The problem with getopt is
not simply bloat (or else you just link a nonbloated implementation);
it's that getopt is simply an awkward legacy API that doesn't fit the
needs of BB very well and thus the calling code is unnecessarily
complex to work around the awkwardness.

Rich