The getopt long thing breaks the tree.

[Tito]

On Monday 5 June 2006 20:01, Rob Landley wrote:
> On Friday 02 June 2006 3:14 pm, Bernhard Fischer wrote:
> > >This trend is normal.  When the mainline gets bloated enough, a
> > > slimmed-down fork emerges.  Dropbear vs openssh.  Galeon vs Mozilla (and
> > > Firefox vs Galeon, and it's still kinda bloated.)  xfce fs kde/gnome. 
> > > uClibc vs glibc, and BusyBox vs most of the GNU tools.
> >
> > Yes. So how is providong means to ignore non-standard extensions which
> > make busybox (as a binary) bigger a bad thing? That's really all what
> > the getopt_long thing did. Nothing fancy, nothing intrusive.
> 
> Something that can make busybox smaller on all platforms needs no further 
> justification. :)
> 
> > >"The nice thing about standards is that there are so many to choose from."
> > > - Andrew S. Tanenbaum, many years ago...
> > >
> > >My lack of caring is deep and profound.  I'm not a fan of the LSB.  There
> > > are multiple conflicting standards.  Wheee.  The application section of
> > > SUSv3 is incomplete, but vaguely sane.  (Only vaguely: We're not
> > > implementing sccs.) And thus is the frame of reference from which we can
> > > document how we diverge when we get around to auditing things.
> >
> > I was under the impression that SUSv3 also implied that we should try to
> > provide a working, minimal set that only uses SUSv3. More fancy features
> > building ontop of eventual extensions should be optional --
> > configurable.
> >
> > Apparently this is not the case, do i understand you correctly?
> 
> I'm not against having both projects, but they're separate things.
> 
> Providing an susv3 conforming environment is something I know how to test, by 
> creating a test suite from reading susv3.  Running in a purely susv3 
> environment isn't something I don't know how to test, because no non-toy 
> environment is purely susv3 (it wouldn't even be able to boot without 
> including stuff that's not in the spec).  And if we work in some theoretical 
> pure susv3 environment but find out that approach sucks on Linux or MacOS X, 
> that's still no good.
> 
> For the first thing, us providing extensions beyond susv3 is not a problem.  
> For the second thing, us using extensions beyond susv3 _is_ a problem.  But 
> some of those extensions do indeed make us smaller, so there's an inherent 
> conflict here, and to resolve it we'd either have to accept sub-optimal 
> solutions on a regular basis or else implement stuff twice, which fights 
> against the goal of simplicity of implementation.
> 
> It's not necessarily an unresolvable problem, but the two issues are _not_ the 
> same thing.
> 
> > >> > Working around specific deficiencies in the Linux emulation of other
> > >> > platforms are just that: workarounds.
> > >>
> > >> Other platforms have no reason to emulate "Linux" (GNU/Linux). Doing
> > >> so will make them necessarily bloated and bogged down by legacy crap.
> > >
> > >I have no reason to care about those other platforms that are neither
> > > Linux nor remotely compatible with it.
> >
> > Well, in case of getopt, one platform adhered to SUSv3, so according to
> > the probably wrong assumption that we aimed for SUSv3 as the (minimum)
> > base,
> 
> That we provide, not that we run on...
> 
> > i thought that it would be good to be able to *run* busybox on 
> > platforms that adhere to SUSv3. That may not have been a valid
> > assumption, though..
> 
> In the specific case of getopt() that permutes our arguments, you're right it 
> sucks and it's possible that doing away with it would help everybody, Linux 
> included. 
hi,
I fear that removing argument permutation (you mean reordering?) will increase bb's
overall size as several applets use it:

int main_applet(int argc, char **argv)
{
	unsigned long opts = bb_getopt_ulflags();

	argv+=optind;
	argc-=optind;

	while(argc--) {
		do_something_with(argv++);
	}
	return 0;
}

The fact to have all non-options as last arguments makes it easy to parse
them.......

Ciao,
Tito

> Parsing command line arguments to a set of flags and option  
> strings shouldn't be brain surgery, and if we're gluing enough crap onto the 
> front of the library function already, it's possible that by not using the 
> library function at all we'll wind up smaller.  Even the function's 
> implementation doesn't shrink, if the lack of permutation means that more 
> apps can use it, and we avoid bugs like the "tar xvjfc" thing, the better 
> behavior might be worth a sufficiently small size penalty.  It's very much 
> worth a look.  For 1.3.0.
> 
> It's possible to arrive at the same goal through different means, and the same 
> implementation for different reasons.  When I say "that's not a compelling 
> reason for me" that's not the end of the argument, but it does mean that 
> hammering on that reason over and over, ignoring what I said, is likely to 
> annoy me. :)
> 
> Rob