svn commit: trunk/busybox/archival

[Rob Landley]

On Saturday 15 October 2005 01:37, Vladimir N. Oleynik wrote:
> landley at busybox.net wrote:
> > I have no idea how to apply bb_getopt_complementally to a --longopt that
> > has no short option.  The documentation from vodz has a bad case of
> > babelfish poisoning, and I can't understand it.  It sort of seems to
> > suggest there is a way, but what it is I have no idea.  So I used \n as
> > the short option, which is fairly unlikely to be used for something else.
> > :)
>
> getopt_ulflasg() support integer (> UCHAR_MAX) longopts now,
> but bb_getopt_complementally - not. Else require bloat code with
> integer array bb_getopt_complementally[] :(
> You make real one true idea with '\n'.
> But, do not loses initialize llist to NULL. (I applied correction already).

Ok, I think what you mean by this is that the approved way to uniquely 
identify long options that do not have a short equivalent is to give their 
fourth entry an integer value outside of the char range, as in:

{ "fruitbasket", 0, 0, 256 }

Unfortunately, there's currently no way to refer to these suckers from 
bb_getopt_complementally[], so no way to indicate that the argument can occur 
multiple times.

What exactly _can_ refer to things by the non-char identifier?  (What purpose 
does giving them a unique identifier outside the char range serve?)

Is there any way we could use the high bits of the last argument to specify 
some of this stuff, perhaps?

{"fruitbasket",0,0,BB_OPT_LIST}

Rob