linux-kernel - Re: [PATCH] net/mlx5: Add a missing macro undefinition

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] [day] [month] [year] [list]

Message-Id: <20200607.163648.1680419872557863264.davem@davemloft.net>
Date:   Sun, 07 Jun 2020 16:36:48 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     xianfengting221@....com
Cc:     leon@...nel.org, saeedm@...lanox.com, kuba@...nel.org,
        netdev@...r.kernel.org, linux-rdma@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net/mlx5: Add a missing macro undefinition

From: Hu Haowen <xianfengting221@....com>
Date: Sun, 7 Jun 2020 14:55:33 +0800

> 
> On 2020/6/7 2:36 PM, Leon Romanovsky wrote:
>> On Sun, Jun 07, 2020 at 01:12:40PM +0800, Hu Haowen wrote:
>>> The macro ODP_CAP_SET_MAX is only used in function
>>> handle_hca_cap_odp()
>>> in file main.c, so it should be undefined when there are no more uses
>>> of it.
>>>
>>> Signed-off-by: Hu Haowen <xianfengting221@....com>
>>> ---
>>>   drivers/net/ethernet/mellanox/mlx5/core/main.c | 2 ++
>>>   1 file changed, 2 insertions(+)
>> "should be undefined" is s little bit over statement, but overall
>> the patch is good.
> 
> 
> Sorry for my strong tone, but my idea is that every macro which is
> defined and used just in a single function, is supposed to be
> undefined
> at the end of its final use, so that you won't get into trouble next
> time if you define a macro with the same name as this one.

The compiler would generate an error if that happened, so you would
not get into "trouble".

I fail to see the value in this change at all, sorry.

Really, what's the point?

Does it make the code harder to read?  No.

Does it cause problems if you accidently want to use that macro name
again in the same compilation unit?  No.

So I have yet to hear a valid "why" to make this kind of change and
I'd like to stop this set of cleanups before it gets out of control
and we have these ugly #undef statements all over the tree.

Thank you.