[RFC] warning about unparenthized macro replacement lists (CERT/MISRA compliance)

Hello!

I have tried to eliminate FPs with heuristics.

I now get warnings in 13 projects

FP
lex generated code: 0 (18)
"*123" and "+1" macros 4 (4)
dangerous macro, no bug 3 (7)
libcap: a->x(y) => a->blk[y] |= .. 1 (1)

TP:
brighton: division in macro 1 (1)
dangerous macro, mistake 0 (1)
real bugs: 4 (4)

The heuristic that removed the LEX FPs is that I don't warn when the last token in the replacement list is a MUL.

It should be possible to improve the heuristics further to avoid more FPs.

But I will look into putting this in clang-tidy also.

Best regards,
Daniel Marjamäki

..................................................................................................................
Daniel Marjamäki Senior Engineer
Evidente ES East AB Warfvinges väg 34 SE-112 51 Stockholm Sweden

Mobile: +46 (0)709 12 42 62
E-mail: Daniel.Marjamaki@evidente.se

www.evidente.se

Hello!

I have tried to eliminate FPs with heuristics.

I now get warnings in 13 projects

FP
lex generated code: 0 (18)
"*123" and "+1" macros 4 (4)
dangerous macro, no bug 3 (7)
libcap: a->x(y) => a->blk[y] |= .. 1 (1)

TP:
brighton: division in macro 1 (1)
dangerous macro, mistake 0 (1)
real bugs: 4 (4)

The heuristic that removed the LEX FPs is that I don't warn when the last token in the replacement list is a MUL.

This also reduces the true positive rate for the dangerous macro
that's a mistake, which is unfortunate. I would probably add this
check to clang-tidy, leave the heuristic out, and then tighten if we
find the FP rate is too high for users. With the original numbers, I
don't think the FP rate was unreasonable for clang-tidy (others may
have different opinions though).

~Aaron