linux-kernel - Re: some numbers on macros

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: <200805250141.09195.m.kozlowski@tuxland.pl>
Date:	Sun, 25 May 2008 01:41:09 +0200
From:	Mariusz Kozlowski <m.kozlowski@...land.pl>
To:	Matthew Wilcox <matthew@....cx>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: some numbers on macros

Hello,

> On Sat, May 24, 2008 at 09:33:50AM -0700, Arjan van de Ven wrote:
> > unused macros in common header files are an indication of stale APIs
> > otoh.. and might be of some interest. (Same for static inline in
> > headers)
> 
> Possibly.  There's likely to be a lot of macros unused like these ones:

Maybe I wasn't precise enough. The script looks for macros which take argument(s)
i.e.

#define foobar() ...

> #define  PCI_X_CMD_MAX_READ     0x000c  /* Max Memory Read Byte Count */
>                                 /* Max # of outstanding split transactions */
> #define  PCI_X_CMD_SPLIT_1      0x0000  /* Max 1 */
> #define  PCI_X_CMD_SPLIT_2      0x0010  /* Max 2 */
> #define  PCI_X_CMD_SPLIT_3      0x0020  /* Max 3 */
> ...
> 
> where the macros embody the PCI specification in code -- possibly we
> don't use them yet, but if we ever did, we'd have the macros to use.

Agreed.

> Another category of false positive is macros that ought to be used,
> but the code that ought to be using them has decided to go its own way.
> That still indicates a bug, but not the one you might initially think.

Agreed.

> In summary, this is probably an interesting exercise, but the results
> would need to be interpreted with care.

Well I'll just go through some of them. This is long term task as its number is quite
big. Maybe I can improve the script some more or apply some other measures. I guess
one can find there all sort of macros and some part of them are leftovers from something
that was there some time ago.

Interesting part would be to write a 'parser' that actually sees the context and understands
cpp directives, that could 'walk' the tree.

	Mariusz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/