On lun, nov 05, 2007 at 12:34:00 +0000, Johannes Schindelin wrote: > > When an option could be an ambiguous abbreviation of two options, the code > used to error out. Even if an exact match would have occured later. > > Test and original patch by Pierre Habouzit. > > Signed-off-by: Johannes Schindelin <Johannes.Schindelin@xxxxxx> > --- > > On Mon, 5 Nov 2007, Pierre Habouzit wrote: > > > When we had at least two long option then followed by another > > one that was a prefix of both of them, then the abbreviation > > detector failed. > > Yeah, I assumed that you would never do such a thing, but I agree > that with recursing option parsing it is much more likely. > > It took me some time to understand your patch, and that the moving > of the UNSET handling was unnecessary. yeah, that's because I dislike where it's done. Each time I read it, I'm under the impression that it clobbers p->opt if this case is not the one used. In fact, I believe that for code clarity we should do what you proposed earlier: disallow `=` in option names (that's rather sane anyway) and drop the `rest` variable altogether, just use your current arg_end and prefixcmp/strncmps. That will incidentally also allow to remove skip_prefix while we're at it. This way we could set p->opt first thing in the function and be done with it instead of doing it two different ways in the function, hence making the reader assume one is wrong or at least questionable. -- ·O· Pierre Habouzit ··O madcoder@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgpGDQHyPqY8p.pgp
Description: PGP signature
