The getopt long thing breaks the tree.

[Rich Felker]

On Wed, May 31, 2006 at 11:24:59PM -0400, Rob Landley wrote:
> On Wednesday 31 May 2006 9:40 pm, Rich Felker wrote:
> > On Wed, May 31, 2006 at 05:27:58PM -0400, Rob Landley wrote:
> > > > What i, personally, care about is standard compliance; There simply is
> > > > no such thing like getopt_long nor "struct option".  See
> > > > http://www.opengroup.org/onlinepubs/009695399/functions/getopt.html
> > >
> > > There's no such thing as mount in the darn standard either.  You should
> > > stop using it immediately.
> >
> > The standard omits mount for a very good reason: not that it should
> > not exist, but that specifying such low-level, administrator-specific
> > things is not the job of the standard but of the particular
> > implementation.
> 
> It is not a complete spec, and it doesn't say we can't rely on things that 
> aren't in the spec.

It doesn't say you can't, but it says that programs that do are not
strictly conforming applications. Whether you care or not...

> There's a difference between the environment we _provide_ and the environments 
> in which we _build_ and _run_.  Pointing to the spec for the environment we 
> provide, I'll look at.  Pointing to the spec about the environment in which 
> we build and run is something about which I _DO_NOT_CARE_.

.. I think we see. :)

> The environment in which we build and run is Linux.

Linux is not a single environment, it's a kernel. The environment
you're talking about is GNU/Linux, which I don't have any interest in
running anymore due to getting thoroughly sick of it after many years
of dealing with all the hacks and bloat.

> There are specs out there that say what 
> a Linux environment should look like.  The Linux Standard Base is one of 
> them.

The LSB is among the most idiotic "specs" I've ever read. It's a waste
of hundreds of pages saying essentially "you must have an ABI
identical to glibc's". Any spec (such as LSB or SVID) that includes
ABI is inherently stupid (from my point of view in case that wasn't
clear) since ABI is obviously an implementation issue and not
something that needs to be standardized.

Moreover if that's not enough LSB actually contradicts POSIX/SUSv3
intentionally due to bugs in Linux. It changes the rules so that the
buggy Linux behavior is not considered buggy. :) Unfortunately this
actually prevents the bugs in Linux from being fixed. :(

> 86open was another (which was pretty big in its day, see 
> http://www.educ.umu.se/~bjorn/mhonarc-files/debian-announce/msg00064.html ), 
> which decided "a common binary standard for x86 Unixes is pointless, just run 
> Linux binaries".  Yes, literally: see http://www.telly.org/86open

Yeah I heard about it. :)

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

> You're bitching about an upstream spec that 
> doesn't specify _init_, so by itself it won't even _boot_.

It doesn't specify init because programs running on the system have no
use in knowing what init is or whether it even exists. This is the
correct way to write a standard. You do not specify the things that
people should not be relying on, and then the implementation is free
to do them in the way it deems most reasonable. For instance, I have
no interest in having a "System V" init program with runlevels,
start/stop/etc. scripts in init.d, etc. This is all huge bloat for the
sake of helping prepackaged programs make themselves run at system
boottime in order to make the host insecure. :)

Because POSIX/SUSv3 are a proper standard, unlike LSB/SVID, I can make
my own init program that just enables auto-reaping of children, runs a
single script, and sleeps for all eternity, and still have a compliant
system. It suits my needs and there's no legitimate reason for any
software but the boot scripts to care about how init works, so why
not?

> > On the other hand, it's reasonable to assume that apps 
> > which have nothing to do with low-level, implementation-specific
> > issues like mounting filesystems and configuring the network should be
> > able to get by with only the standard interfaces, and work
> > out-of-the-box on any (mostly-) posix compliant system.
> 
> If you talk about "this test case breaks on MacOS X", that's real.  If you say 
> "this does not conform to the spec" I'll show you a spec it conforms to, even 
> if it's the gcc man page or Johnathan Corbet's Linux device drivers book.

I've said multiple times: what I talk about is "this test case breaks
on my implementation of the C library". My implementation is based
exclusively on a reading of SUSv3, and aside from the fact that I
insist on never imposing arbitrary limits or unbounded time/memory use
when it's not necessary (I consider these quality/security issues), it
intentionally does not provide anything beyond what the standards
require.

This is not pedantry for the sake of pedantry. It's a matter of
keeping the implementation small, fast, and simple, and of ensuring
that implementation may later be replaced by better ones which work in
a different manner yet which cannot have the same (extended) behavior
as the original code. I can cite several major examples in glibc where
adding nonstandard functionality to various functions has made it
difficult (coding-wise, or often memory/performance-wise!) to update
the functions to conform to modern standards (see fnmatch for one,
uhg!!). Overspecification is the bane of code because it essentially
locks you into one implementation, and over time that implementation
will eventually become undesirable.

> > I apologize that you feel like these issues are wasting your time.
> 
> No, I feel they're introducing new goals to the project.  We try to provide a 
> SUSv3 environment, but A) that's just an config option, B) what we provide it 
> on is Linux and things that are more or less compatible with Linux.  Changes 
> to support non-linux platforms which require such extensive changes to 
> BusyBox that they can't be confined to something like platform.h may not be 
> worth doing.

Overall I agree. I hate platform-based ifdefs and the like. The
minimum I'd like to see (and which I have been submitting patches for)
is to make all the applets that have no dependence on Linux-specific
functionality so that they work on any SUSv3-compliant system.

A slightly higher level that would also be nice is to make some of the
Linux-specific applets less dependent on the particular libc used, so
that they might work with dietlibc, newlib, my implementation, or
other weird stuff out there that could be useful in embedded
applications. I do NOT propose doing this with ifdefs, but instead
with minor changes that do not break glibc/uClibc but allow the code
to work with non-glibc-compat libs as well.

> > Would it perhaps be better if the people who care about them try not
> > to bother you with issues that will make the code "dirty" (like
> > ifdefs) and instead try to develop a clean way of handling these sorts
> > of issues that will be acceptable to the way you want the project
> > maintained?
> 
> How much OSX support did Erik do?  How much did Bruce Perens do?
> 
> Saying "MacOS X doesn't have a getopt implementation that does this" is one 
> thing, and the obvious thing to do is implement the missing piece to overcome 
> the deficiency in MacOS's Linux compatability.  Saying "getopt is linux 
> specific and therefore broken, so we shouldn't use it" is BY DEFINITION 
> wrong.

I'll try not to have a position on this one way or the other.

> It's the API Linux has, therefore it's what busybox should be 
> primarily using.

It's the api GNU libc has. Last I checked there's no __NR_getopt_long
in asm/unistd.h. :)

Rich