netdev - Re: [PATCH ethtool 2/3] netlink: Fix maybe uninitialized 'meters' variable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 13 Jan 2023 16:12:45 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Michal Kubecek <mkubecek@...e.cz>
Cc:     netdev@...r.kernel.org, Markus Mayer <mmayer@...adcom.com>,
        Andrew Lunn <andrew@...n.ch>
Subject: Re: [PATCH ethtool 2/3] netlink: Fix maybe uninitialized 'meters'
 variable



On 1/13/2023 4:09 PM, Michal Kubecek wrote:
> On Fri, Jan 13, 2023 at 03:31:47PM -0800, Florian Fainelli wrote:
>> GCC12 warns that 'meters' may be uninitialized, initialize it
>> accordingly.
>>
>> Fixes: 9561db9b76f4 ("Add cable test TDR support")
>> Signed-off-by: Florian Fainelli <f.fainelli@...il.com>
>> ---
>>   netlink/parser.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/netlink/parser.c b/netlink/parser.c
>> index f982f229a040..6f863610a490 100644
>> --- a/netlink/parser.c
>> +++ b/netlink/parser.c
>> @@ -237,7 +237,7 @@ int nl_parse_direct_m2cm(struct nl_context *nlctx, uint16_t type,
>>   			 struct nl_msg_buff *msgbuff, void *dest)
>>   {
>>   	const char *arg = *nlctx->argp;
>> -	float meters;
>> +	float meters = 0.0;
>>   	uint32_t cm;
>>   	int ret;
>>   
> 
> No problem here either but it's quite surprising as I check build with
> gcc versions 7 and 11-13 (10-12 until recently) for each new commit and
> I never saw this warning. As the warning is actually incorrect (either
> parse_float() returns an error and we bail out or it assigns a value to
> meters), it may be a gcc issue that was fixed in a later version. But
> initializing the variable does no harm so let's do it.

Yes that might be the case, this was seen with GCC 11.3 as well. I 
definitively did use a GCC12 pre-release at some point, too.
-- 
Florian