
On Thursday 07 May 2009, Detlev Zundel wrote:
If so, it still seems to be a somewhat rude way to do it. How long will it take the gcc maintainers to produce a "warning: unused variable is used" warning? ;)
I prefer to do it this way instead of encasing the variable declaration into another #ifdef ... #endif section. This is used in many cases in the Linux kernel btw. Here the macro "__maybe_unsed" is defined to "__attribute__((unused))".
In many cases? a rgrep on a recent kernel counts 84 incantations, which is not much for the Linux kernel, I believe.
Perhaps it's quite new to the Linux kernel. I just spotted it the first time a few weeks ago and thought: "What a nice way to remove some of the ugly #ifdef's in U-Boot!". :)
So what should I do now? Should I revert to another #ifdef in the variable declaration? Or is the current version ok?
I'm not too sure myself. What really tickles me, and what speaks against using this attribute, is the fact that the "unused" attribute is itself not part of an #ifdef, whereas the intention clearly is that this attribute should only be applied when the ifdefs erases code.
BTW: The resulting code/data length is the same, comparing a version with #ifdef's, the attribute version or a version with the variable declaration intact and the warnings.
Now currently this connection maybe clear for the writer of the patch, but it is in no way obvious in the code. So theoretically, when the #ifdef gets removed, nobody will think about the "unused" attributes, forget them and then we have effectively lost correct warnings.
This could be the case. But this could happen to the #ifdef version as well. That the #ifdef'ed variable declaration stays in the code after removing the code referencing the variables.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================