Re: [PATCH v2 2/8] env--helper: new undocumented builtin wrapping git_env_*()

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

 



On Fri, Jun 21 2019, Junio C Hamano wrote:

> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> ...
>> as I am getting
>>
>>     error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>
>> from here.
>>
>> Giving an otherwise useless initial value to ret would be a
>> workaround.
>
> I've added this on top of the topic before merging to keep the
> integration going at least for now.
>
> commit 8f86948797a1152594a8dee50d0878604fec3e80
> Author: Junio C Hamano <gitster@xxxxxxxxx>
> Date:   Thu Jun 20 15:13:14 2019 -0700
>
>     SQUASH??? avoid maybe-uninitialized
>
> diff --git a/builtin/env--helper.c b/builtin/env--helper.c
> index 2bb65ecf3f..29df0567fb 100644
> --- a/builtin/env--helper.c
> +++ b/builtin/env--helper.c
> @@ -43,6 +43,9 @@ int cmd_env__helper(int argc, const char **argv, const char *prefix)
>  		usage_with_options(env__helper_usage, opts);
>
>  	switch (cmdmode) {
> +	default:
> +		BUG("wrong cmdmode");
> +		break;
>  	case ENV_HELPER_BOOL:
>  		tmp_int = strtol(env_default, (char **)&env_default, 10);
>  		if (*env_default) {

In this case the compiler is wrong, and gcc/clang in e.g. Debian
unstable doesn't warn about this since the analyzer sees that it's
impossible for "ret" to be uninitialized.

I can change it anyway, and if I rewrite the UI of this command it might
go away anyway.

Just thought I'd ask if appeasing older analyzers is what we want for
these sorts of optional warnings in general.



[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