John Levon wrote:
> On Mon, Jun 09, 2008 at 02:19:23PM -0400, Dan McDonald wrote:
>
>
>> Until you do something like:
>>
>> if (foo)
>> timerclear(&t); /* XXX KEBE SAYS SYNTAX ERROR */
>> else
>> something_else();
>>
>> I thought we were trying to not be different than the rest of the world now?
>>
>
> Lint should be fixed to understand do {} while (0). We already have a
> workaround (__lintzero) in kernelspace for this. The relevant bug:
>
> 4821302 lint should not complain about the safest way to construct
> complicated macros
>
> regards
> john
>
Is it reasonable to expect that the bug in lint will be fixed in time
for this case to integrate?
(Based on the included man page in this case, and the bug state of that
CR, I don't think so.) So, rather than add yet another reason to use
/*LINTED*/ while we wait for lint to be fixed (the CR is a P4, so I'm
not holding my breath), can we at least stick a workaround (perhaps with
a comment requesting it be removed, and a cross-linked CR -- via SEE
ALSO) in the implementation for this case?
Having to put /*LINTED*/ (or other suppression directives) above or
around standard usage of system supplied macros and functions is, IMO,
one of the biggest disincentives to using lint in the first place. I'd
like to see the need to use such reduced, rather than increased. (And
yes, IMO, changes that impact the compatibility/usefulness of standard
tools like lint *is* architectural.)
-- Garrett
