Re: [PATCH 02/12] parse-options: add two helper functions

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 27, 2010, 18:22 UTC
Message-ID: <7vaaqggwsh.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1277558857-23103-3-git-send-email-struggleyb.nku@gmail.com>

Show 22 quoted lines

> diff --git a/parse-options.c b/parse-options.c
> index cbb49d3..013dbdb 100644
> --- a/parse-options.c
> +++ b/parse-options.c
> @@ -439,6 +439,27 @@ unknown:
>  	return PARSE_OPT_DONE;
>  }
>  
> +const char *parse_options_current(struct parse_opt_ctx_t *ctx)
> +{
> +	return ctx->argv[0];
> +}
> +
> +int parse_options_next(struct parse_opt_ctx_t *ctx, int retain)
> +{
> +	if (ctx->argc <= 0)
> +		return -1;
> +
> +	if (retain == 1)
> +	{
> +		ctx->out[ctx->cpidx++] = ctx->argv[0];
> +	}

Style. Either drop the unnecessary curly pair, or open the curly at the end of the line that has the closing parenthesis of "if" condition.

These two functions makes sense. You could then use parse-options-step to let the machinery mostly be driven by the usual table lookup, and when (and only when) the machinery says "I don't know what this is", you can check "current" to see what it is (e.g. it may be "-L"), handle it yourself, and if you need to do something different (e.g. eat the <path> that immedately follows "-L"), you can use "next" to skip it without ever showing that to the table based parseopt machinery.

I however wonder why you would need two passes if you have these two APIs into parse-options machinery, though...