linux-kernel - RE: [PATCH][next] tipc: remove redundant assignment to ret, simplify code

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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Thu, 11 Apr 2024 11:04:15 +0000
From: Tung Quang Nguyen <tung.q.nguyen@...tech.com.au>
To: "Colin King (gmail)" <colin.i.king@...il.com>, Dan Carpenter
	<dan.carpenter@...aro.org>
CC: Jon Maloy <jmaloy@...hat.com>, Ying Xue <ying.xue@...driver.com>, "David S
 . Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub
 Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"tipc-discussion@...ts.sourceforge.net"
	<tipc-discussion@...ts.sourceforge.net>, "kernel-janitors@...r.kernel.org"
	<kernel-janitors@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH][next] tipc: remove redundant assignment to ret, simplify
 code

>Subject: Re: [PATCH][next] tipc: remove redundant assignment to ret, simplify code
>
>On 11/04/2024 11:31, Dan Carpenter wrote:
>> On Thu, Apr 11, 2024 at 10:04:10AM +0000, Tung Quang Nguyen wrote:
>>>>
>>> I suggest that err variable should be completely removed. Could you
>>> please also do the same thing for this code ?
>>> "
>>> ...
>>> err = skb_handler(skb, cb, tsk);
>>> if (err) {
>>
>> If we write the code as:
>>
>> 	if (some_function(parameters)) {
>>
>> then at first that looks like a boolean.  People probably think the
>> function returns true/false.  But if we leave it as-is:
>>
>> 	err = some_function(parameters);
>> 	if (err) {
>>
>> Then that looks like error handling.
>>
>> So it's better and more readable to leave it as-is.
>>
>> regards,
>> dan carpenter
>
>I concur with Dan's comments.
>
>Colin
I have a different view.
It does not make sense to me to use stack variable 'err' just for checking return code of the functions (__tipc_nl_add_sk/ __tipc_add_sock_diag) that we know always return true on error.