linux-kernel - Re: [patch 01/10] compiler: define __attribute_unused_

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:	Thu, 3 May 2007 12:24:17 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Adrian Bunk <bunk@...sta.de>
cc:	Rusty Russell <rusty@...tcorp.com.au>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 01/10] compiler: define __attribute_unused__

On Thu, 3 May 2007, Adrian Bunk wrote:

> > static external variables are certainly still static code and gcc issues 
> > the proper warnings if I do:
> > 
> > 	static struct bootnode nodes[MAX_NUMNODES];
> > 
> > and I never reference nodes.
> 
> No disagreement.
> 
> But you said:
>   What about automatic or static external variables that are declared but ...
> 

Ahh, I see the problem.  I was talking about "automatic variables" and 
"static external variables" implicitly, both of which emit compiler 
warnings if they are unreferenced as we saw in the arch/i386/pci/init.c 
case and the example above, respectively.

The only advantage this gives us as opposed to just removing an 
unreferenced variable completely is the case when its usage depends on 
multiple preprocessor macros.  Like in the arch/i386/pci/init.c example, 
the use of 'type' depends on CONFIG_PCI_DIRECT or CONFIG_PCI_MMCONFIG.  It 
gets sloppy pretty quickly when we're adding

	#if defined(CONFIG_PCI_DIRECT) || defined(CONFIG_PCI_MMCONFIG)

around the variable declarations.  Unfortunately we still have the 
drawback of perhaps leaving abandoned declarations in the code but now 
there will be an easy way to detect it: defining __maybe_unused and __used 
to be empty.  Then we won't have hardcoded __attribute__ ((unused)) text 
sprinkled around the tree that would require examination on an individual 
basis.

		David
-
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/