Re: [PATCH] parse-options: abbreviation engine fix.

[Pierre Habouzit <madcoder@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]

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@gmx.de>
> ---
> 
> 	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@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]