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 checkedFor 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