netdev - Re: [PATCH net-next v25 01/13] rtase: Add support for a pci table in this module

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]

Message-ID: <c8a42211-3b39-4258-93a7-354ce729eb7f@web.de>
Date: Mon, 29 Jul 2024 18:44:18 +0200
From: Markus Elfring <Markus.Elfring@....de>
To: Andrew Lunn <andrew@...n.ch>, Justin Lai <justinlai0215@...ltek.com>,
 netdev@...r.kernel.org, kernel-janitors@...r.kernel.org
Cc: Jakub Kicinski <kuba@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jiri Pirko <jiri@...nulli.us>, Joe Damato <jdamato@...tly.com>,
 Larry Chiu <larry.chiu@...ltek.com>, Paolo Abeni <pabeni@...hat.com>,
 Ping-Ke Shih <pkshih@...ltek.com>, Ratheesh Kannoth <rkannoth@...vell.com>,
 Simon Horman <horms@...nel.org>
Subject: Re: [PATCH net-next v25 01/13] rtase: Add support for a pci table in
 this module

>> …
>>> +++ b/drivers/net/ethernet/realtek/rtase/rtase.h
>>> @@ -0,0 +1,338 @@
>> …
>>> +#ifndef _RTASE_H_
>>> +#define _RTASE_H_
>> …
>>
>> I suggest to omit leading underscores from such identifiers.
>> https://wiki.sei.cmu.edu/confluence/display/c/DCL37-C.+Do+not+declare+or+define+a+reserved+identifier
>
> Do you have a reference to a Linux kernel document which suggests not
> to do this?

I assume that you would become interested to clarify corresponding concerns
according to compliance (or deviations) from the standard of the programming language “C”.

> My grep foo is not great, but there appears to be around 20,000
> instances of #define _[A-Z] in the kernel. So i doubt adding a couple
> more is going to be an issue.

I suggest to improve case distinctions accordingly.
Can it be more desirable to avoid undefined behaviour another bit?

How will development interests evolve further?

Regards,
Markus