Re: [PATCH v3 03/10] parse-options.[ch]: consistently use "enum parse_opt_result"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Nov 06 2021, SZEDER Gábor wrote:

> 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@xxxxxxxxx>
>> ---
>
>> 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!




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux