Re: [PATCH v3 03/10] parse-options.[ch]: consistently use "enum parse_opt_result"
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Nov 6, 2021, 21:31 UTC
- Message-ID
- <211106.86lf21ezqx.gmgdl@evledraar.gmail.com>
- In-Reply-To
- <20211106191103.GA5811@szeder.dev>
On Sat, Nov 06 2021, SZEDER Gábor wrote:
Show 65 quoted lines
> On Fri, Oct 08, 2021 at 09:07:39PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> Use the "enum parse_opt_result" instead of an "int flags" as the
>> return value of the applicable functions in parse-options.c.
>>
>> This will help catch future bugs, such as the missing "case" arms in
>> the two existing users of the API in "blame.c" and "shortlog.c". A
>> third caller in 309be813c9b (update-index: migrate to parse-options
>> API, 2010-12-01) was already checking for these.
>>
>> As can be seen when trying to sort through the deluge of warnings
>> produced when compiling this with CC=g++ (mostly unrelated to this
>> change) we're not consistently using "enum parse_opt_result" even now,
>> i.e. we'll return error() and "return 0;". See f41179f16ba
>> (parse-options: avoid magic return codes, 2019-01-27) for a commit
>> which started changing some of that.
>>
>> I'm not doing any more of that exhaustive migration here, and it's
>> probably not worthwhile past the point of being able to check "enum
>> parse_opt_result" in switch().
>>
>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>> ---
>
>> diff --git a/parse-options.c b/parse-options.c
>> index 9c8ba963400..f718242096c 100644
>> --- a/parse-options.c
>> +++ b/parse-options.c
>> @@ -699,13 +699,14 @@ static void free_preprocessed_options(struct option *options)
>> free(options);
>> }
>>
>> -static int usage_with_options_internal(struct parse_opt_ctx_t *,
>> - const char * const *,
>> - const struct option *, int, int);
>> -
>> -int parse_options_step(struct parse_opt_ctx_t *ctx,
>> - const struct option *options,
>> - const char * const usagestr[])
>> +static enum parse_opt_result usage_with_options_internal(struct parse_opt_ctx_t *,
>> + const char * const *,
>> + const struct option *,
>> + int, int);
>> +
>> +enum parse_opt_result parse_options_step(struct parse_opt_ctx_t *ctx,
>> + const struct option *options,
>> + const char * const usagestr[])
>> {
>> int internal_help = !(ctx->flags & PARSE_OPT_NO_INTERNAL_HELP);
>>
>> @@ -839,10 +840,11 @@ int parse_options_end(struct parse_opt_ctx_t *ctx)
>> return ctx->cpidx + ctx->argc;
>> }
>>
>> -int parse_options(int argc, const char **argv, const char *prefix,
>> - const struct option *options,
>> - const char * const usagestr[],
>> - enum parse_opt_flags flags)
>> +enum parse_opt_result parse_options(int argc, const char **argv,
>
> The return type of this function should have been left unchanged,
> because it contains only one return statement:
>
> return parse_options_end(&ctx);
>
> and parse_options_end() does return an int.Indeed. I'll submit a fix for that sooner than later. I think I got that and *_step() mixed up, parse_options() just returns "here's what we've got left in argc".
I think due to C's happy-go-lucky enum-as-int semantics I'll probably leave it until post-2.34, i.e. I don't think it can/will break anything at runtime, but should be fixed for sure.
Thanks for spotting!