Hi Stefan,
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.
Actually my argument was never about resulting code or data size, but about maintainability.
My clear view here is to put as much information as possible into the sources. So if at all possible, let the compiler know. If this is not possible then let the user know by using constructs that at least show a connection to the human reader - i.e. using ifdef blocks with the same name. If that is also not possible then the least we should do is to write a comment with the original intent.
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.
Someone touching one block with ifdefs will surely - or better should and *can* - check other blocks with the same condition. Using an __unused attribute breaks this connection.
Cheers Detlev