if we don't zero it after closing it we re-close a filehandle that isn't
open, and since this is a file _pointer_ it segfaults on a double free.
Yeah, subtle bug. I need to break this out into separate functions if I can
figure out how to avoid making the code larger while doing so. Part of
the general -a and -o remount work I need to do, but that's after 1.1.0...
Not buying it, eh?
I know I said new features before 1.1, but, well... (I was weak!)
The config file and hotplug modes aren't implemented yet. Might take a stab at
those tomorrow. (I _should_ go back to focusing on the bug triage list.)
messages, C) can show the current association (if any) when called
with only one argument. Update the documentation a lot too.
Remind me to add a test suite for this thing. I think I've figured out
how to handle root-only testsuites...
fixes bug #113 and satisfies a personal need at the same time.
output compares identically to util-linux version. (with
exception of whitespace differences on last lines of output with
non-uniform length, which are neither fixed nor worsened by this
change.)
- new bb_getopt_ulflags features: check max and min args, convert first argv to options special for ar and tar applets
- use bb_default_error_retval for env applet
- more long opt compatibility, can set flag for long opt struct now
- more logic: check opt-depend requires and global requires, special for 'id' and 'start-stop-daemon' applets.
./busybox getopt -n one -n two woot
./busybox getopt -o one -o two woot
This entire applet is still an enormous pile of garbage, which I can't clean
up because I really have no idea what it's for. (Both "man getopt" and trying
it out on the command line a bit fail to enlighten me. Reading the code, the
fact half of it seems to be special cases for bash vs tcsh does not fill me
with confidence.)
added to the list, and my assumption that nfsmount() actually called
mount() was incorrect (and I coded it wrong anyway; I hate having to touch
codepaths I can't personally test).
can never be made because useMtab is initialized to 0, and all the other
assignments of that variable assign 0 to it. Any compiler that can perform
simple constant propogation on local variables will optimize away if statements
testing against that variable, thus the call to erase_mtab() will never be
made.
When compiling for arm using gcc 3.3.3 with FEATURE_MTAB_SUPPORT disabled,
the linker complains that it can't find erase_mtab(). The arm optimizer isn't
exactly the brightest member of the family, and apparently needs to be hit over
the head with a hammer to get its' attention...
