[U-Boot] [PATCH] ppc4xx: Add Sequoia RAM-booting target

Detlev Zundel dzu at denx.de
Fri May 8 14:34:09 CEST 2009


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

-- 
By all means let's be open-minded, but not so open-minded that our
brains drop out.
                                                -- Richard Dawkins
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de


More information about the U-Boot mailing list