Rockbox mail archiveSubject: Re: Should we enable -Wmissing-declarations?
Re: Should we enable -Wmissing-declarations?
From: Rafaël Carré <funman_at_videolan.org>
Date: Wed, 21 Dec 2011 23:02:22 -0500
Le Wed, 21 Dec 2011 13:53:06 -0500,
Boris Gjenero <boris.gjenero_at_gmail.com> a écrit :
> With -Wmissing-declarations, gcc can warn about non-static global
> functions and data without a previous declaration. What do others think
> about the idea of enabling the warning for the core, after some cleanup?
> I examined warnings about stuff in the core, and this is what I found:
> * Missing static. Sometimes a function is only static in some
> * Missing includes. In these cases, nothing ensures that the function
> matches the prototype. Also, attributes (such as INIT_ATTR) which may be
> found in the prototype don't apply to the function.
> * A function that's not used in the current configuration. The correct
> header file is included, but preprocessor conditionals exclude the
> prototype. Sometimes, it's a function which does nothing and exists for
> a feature that isn't implemented for that target. I'm not sure if those
> need conditionals or deletion.
> * Functions used in other files, where the prototypes are only in C
> files using the functions. I think this is undesirable. It defeats the
> protection offered by prototypes.
> * Totally unused code
> * Interrupt handlers and other code only referenced from assembler,
> where prototypes are not helpful. This would require a prototype just to
> avoid the warning. There's a lot of this in Rockbox, and it's the main
> disadvantage of -Wmissing-declarations.
> I did not examine code outside of core because there are far more
> warnings there. In some cases it's code from other projects, where
> changes could make backporting of fixes harder. For these reasons, I'm
> only suggesting -Wmissing-declarations for the core.
It's a good idea to enable this for the core.
I would say plugins are less critical.
Codecs on the other hand might benefit from it, even if we copy
external code we modify it heavily.
-- Rafaël CarréReceived on 2011-12-22