Re: [RFC PATCH v3 5/6] parse-options: parse into argv_array

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 30, 2020, 23:41 UTC
Message-ID: <xmqqsgd8606c.fsf@gitster.c.googlers.com>
In-Reply-To: <xmqqmu3i9kvg.fsf@gitster.c.googlers.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 22 quoted lines

> Be it argv_array or strvec, I think this is a useful thing to do.
>
> I grepped for the users of OPT_STRING_LIST() to see if some of them
> are better served by this, but none of them stood out as candidates
> that are particularly good match.
>
>> +int parse_opt_argv_array(const struct option *opt, const char *arg, int unset)
>> +{
>> +	struct argv_array *v = opt->value;
>> +
>> +	if (unset) {
>> +		argv_array_clear(v);
>> +		return 0;
>> +	}
>> +
>> +	if (!arg)
>> +		return -1;
>
> I think the calling parse_options() loop would catch this negative
> return and raise an error, but is it better for this code to stay
> silent or would it be better to say that opt->long_name/short_name 
> is not a boolean?

I am still waiting for this to be answered, but I queued the whole topic, these last two steps included, just to see how bad adjusting to the strvec API migration would be. It wasn't too bad.

I would not recommend you, or other contributors who use argv-array API in their topics, to build on top of jk/strvec, not just yet, as I expect it to go through at least one more reroll to update the details.

Thanks.