[MPlayer-cvslog] [PATCH] GCC: Do not warn about unused paramters (was Re: r36944 - in trunk/gui/win
Alexander Strasser
eclipse7 at gmx.net
Wed Feb 26 17:26:09 CET 2014
On 2014-02-26 16:05 +0100, Ingo Brückl wrote:
> Alexander Strasser wrote on Wed, 26 Feb 2014 15:22:33 +0100:
>
> > BTW @ all:
> > Why don't we have -Wno-unused-parameter in CFLAGS?
>
> > I can hardly even think of a case where an unused parameter warning
> > would be relevant. Also I cannot remember a single occasion where it
> > mattered in practice.
>
> An unused variable (besides one in a callback function that has a fixed
> parameter list) is either a leftover or bad programming style (IMO).
> I want to be informed about any junk lying around.
>
> And for the mentioned callback functions something like mp_unused() would
> indicate that not all of the parameters are relevant in this particular case
> (while allowing the usage of -Wunused-parameter).
>
> > Adding the above mentioned flag eliminates 2000+ unused parameter
> > warnings here if I did not mess up my measurements.
>
> > Patch attached.
>
> No surprise, I object.
That is fine, but naturally I disagree with you on that point :)
First your leftover/bad programming argument can be helped better
by re-iterating over the functions taking a hard look at their docs
(if available) and signature (including name, parameters, and return
type) and a glimpse over their respective function bodies. You are
likely to improve things much more this way.
Second it is not only for callbacks where unused parameters
may be wanted. E.g. if you have a parameter that just doesn't
matter for a particualar implementation of a function, so at
some point probably deeper in the call graph, it will end-up
unused or it must be marked unused explicitly.
Notice that I am only arguing about unused function parameters
and *not* unused variables.
Alexander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-cvslog/attachments/20140226/4bafd4da/attachment.asc>
More information about the MPlayer-cvslog
mailing list