[MPlayer-dev-eng] [MPlayer-cvslog] [PATCH] GCC: Do not warn about unused paramters (was Re: r36

Alexander Strasser eclipse7 at gmx.net
Thu Feb 27 22:44:37 CET 2014


On 2014-02-27 02:19 +0100, Hans-Dieter Kosch wrote:
> Ingo Brückl wrote:
> >Well, if it were so easy, you wouldn't need compiler warnings at all.
> >Actually, it often is just the warnings that point out to have a closer
> >and harder look. I consider (as much) compiler warning options (as possible
> >and reasonable) a valuable help. (Which is the reason why I'm using a few
> >more locally.)
> 
> I fully agree. Pedantic compiler warnings often helped me to track
> down weired issues. The more warnings enabled and the less warnings
> output, the more reliable the result. I always feel uncomfortable
> compiling code with lots of warnings, which seems to work anyway,
> though. IMHO, a close look at the source is often easier than an
> extensive gdb session.

  I have the feeling you are getting me wrong :(
  
  I am all for compiler warnings in general, but I find this particular
warning, "parameter unused", is not a gain at all. I am not talking about
"variable unused" which is a different warning.

  As I mentioned initially I experienced no case the "parameter unused"
warning did ever point to an actually existing problem. That is not
sufficient as it is no falsification, but as I said in my original
reply I cannot even really imagine cases where it would be helpful.

  The other thing about this particular warning is, that subroutines or
functions, to use C lingo, are quite a different thing for me. Their
signatures define the seams of your coding, they define interfaces API
and ABI and they should often not be changed carelessly just to cater for
some warning.


  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-dev-eng/attachments/20140227/00e32136/attachment.asc>


More information about the MPlayer-dev-eng mailing list