On Tuesday, 27 December 2022 12:58:41 CET Linus Lüssing wrote: > On Tue, Dec 27, 2022 at 10:07:36AM +0100, Sven Eckelmann wrote: > > ecsv/pu: checkpatch ./net/batman-adv/multicast_forw.c > > ----------------------------------------------------- > > > > CHECK: Macro argument reuse 'num_dests' - possible side-effects? > > #25: FILE: ./net/batman-adv/multicast_forw.c:25: > > +#define batadv_mcast_forw_tracker_for_each_dest(dest, num_dests) \ > > + for (; num_dests; num_dests--, (dest) += ETH_ALEN) > > > > total: 0 errors, 0 warnings, 1 checks, 274 lines checked > > > > For this I'm not quite sure how to best silence this. I tried > the workaround of passing num_dests as a pointer and dereferencing > it inside the macro: > > #define batadv_mcast_forw_tracker_for_each_dest(dest, num_dests) \ > for (; (*(num_dests)); (*(num_dests))--, (dest) += ETH_ALEN)
This doesn't make a lot of sense. The checkpatch output is about using the
same argument multiple times. It is explicitly talking about following
situation.
#define asd(b) \
do {
if (b)
printk("Foobar %d\n", b);
while (1)
....
asd(x++);
Which would then be transformed to following by the preprocessor:
do {
if (x++)
printk("Foobar %d\n", x++);
while (1)
So your x after the "call" of asd() would (sometimes) not be x+1 but x+2.
> So just like you'd do if you would want intentional side-effects with
> a normal function. But seems like checkpatch does not recoginze it.
>
> Also all the other for_each macros in the kernel code have
> side-effects, as far as I know?
>
> Or would you have another idea?
Provide a patch for checkpatch or build_test.git (which would otherwise send
this output every day).
Kind regards,
Sven
signature.asc
Description: This is a digitally signed message part.
