On Sep 22, 2014, at 1:05 PM, Peter Zijlstra <pet...@infradead.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
signature.asc
Description: Message signed with OpenPGP using GPGMail
