Pierre Habouzit <madcoder@xxxxxxxxxx> writes: > Unrelated but worth to note: many parse_options users just don't care > about argv[0] and having it kept each time would rather be a pain for > them (they would need to call argv++, argc-- themselves). Not necessarily. If they were parsing by hand, they were written to deal with the fact that argv[0] is not the program argument (iow, they start counting from one). And before and after calling parse_options(), they need to change that assumption anyway, because parse_options() makes argv[0] disappear. See for example these: * 5eee6b2 (Make builtin-reset.c use parse_options., 2008-03-04) The caller used to start counting from 1, after the conversion it has to count from 0. * 8320199 (Rewrite builtin-fetch option parsing to use parse_options()., 2007-12-04) * 3968658 (Make builtin-tag.c use parse_options., 2007-11-09) The caller used to say (i==argc) is "no param" case, now it has to say "!argc" is the equivalent condition. I am not saying that forcing these callers to change their loop invariants in order to use parse_options() was bad. I am saying that your "would rather be a pain for them" is a bogus argument --- they needed to pay that price when converting to parse_options() that munges argv[0] anyway. But this argv[0] munging exactly is why parse_options() hurts users who want to cascade option parsing. Didn't one of the recent series have an option to tell parse_options() to start parsing from argv[0] (persumably because it got an argument array from somebody who munges it to drop argv[0])? I think it was merge-in-C from Miklos, but the approach feels very much backwards. The caller should be (at least) able to choose to say KEEP_ARGV0 like one of your patch does. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
