linux-kernel - Re: [PATCH] sched: Remove nested extern

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: <D3423D3A-814F-4E22-A84B-61D76D137A98@intel.com>
Date:	Mon, 22 Sep 2014 20:59:32 +0000
From:	"Rustad, Mark D" <mark.d.rustad@...el.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	"sparse@...isli.org" <sparse@...isli.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"richard.weinberger@...il.com" <richard.weinberger@...il.com>,
	"linux-sparse@...r.kernel.org" <linux-sparse@...r.kernel.org>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"computersforpeace@...il.com" <computersforpeace@...il.com>
Subject: Re: [PATCH] sched: Remove nested extern

On Sep 22, 2014, at 1:05 PM, Peter Zijlstra <peterz@...radead.org> wrote:

> On Mon, Sep 22, 2014 at 07:32:04PM +0000, Rustad, Mark D wrote:
>> I assume that nested-externs is included in W=2 because many uses of
>> them, especially with function prototypes, creates a risk of inconsistent
>> declarations. The kernel has a fair number of them that seem to have
>> been added to disentangle include files. If they are judged to be
>> worthwhile, then it would be good to silence the warnings so that
>> attention can be given to other instances of the warnings. If those
>> nested externs are not worth the risk, well that is a different conversation.
> 
> So would using something like LTO not be way better at actually finding
> the problems, seeing how it can actually see the inconsistency in
> declarations.
> 
> It seems to me that banning the use of nested extern is misguided as
> they are a useful tool; they provide some means of keeping symbols from
> being globally visible even though they actually are. Its a really poor
> man's 'private', but its the best C provides.

By using the macros the use of nested externs can be discouraged without
being banned. Presence of a DIAG_IGNORE macro should mean that the exception
has been noted and accepted. And the macro remains as an indicator of that.
Or to be taken as a warning label: readers choice perhaps.

> Also, why do you care about W=2 nonsense anyhow? They're default
> disabled for a reason.

Because I have found that enabling many warnings helps identify problems
in code and it has been my standard practice since about 1999 to do so.
The compiler warnings are really just another form of static analysis,
and I use it routinely on every compile. Here is how routinely: I have
W=1 in my environment, W=12 is just too painful. I would change that
default to W=12 if it wasn't insane to do so.

In my own code, I use way more warnings than even W=12 enables and in
that code I just resolve them. I had never resorted to using the attributes
in my own code, but they are an available tool.

I just finally thought it might be time to consider opening up a new
method to manage them for the kernel.

-- 
Mark Rustad, Networking Division, Intel Corporation

Download attachment "signature.asc" of type "application/pgp-signature" (842 bytes)