On 23/04/2025 7:16 pm, Lira, Victor M wrote: > Continuing a discussion from before: > > On 4/22/2025 11:44 PM, Jan Beulich wrote: >> Caution: This message originated from an External Source. Use proper >> caution when opening attachments, clicking links, or responding. >> >> >> On 23.04.2025 01:43, victorm.l...@amd.com wrote: >>> memmove. >>> - Tagged as `deliberate` for ECLAIR. >>> >>> + * - R5.5 >>> + - Clashes between function-like macros and function names are >>> + deliberate >> They may or may not be deliberate, depending on context. I don't >> think it's a >> good move to deviate this more widely than necessary. If I get the >> expression >> above (in deviations.ecl) right, even >> >> void func1(int); >> void func2(int); >> >> #define func1() func2(0) >> #define func2() func1(0) >> >> would be deviated, which I don't think we want. Especially when, in a >> less >> contrived scenario, the clash may not easily be visible. > OK, I see the issue for different functions. Does it make sense to say > it's deliberate when it's the same identifier? > > void func1(int); > ... > #define func1() func1(0) > > Could this be deviated?
The issue here is we've got a load of violations, and different reasoning. e.g. all the bitops violations are valid and need fixing. I have a plan for how to do so, and 0 time. These are the overwhelming majority of violations. pirq_cleanup_check() is horrible. cpu_has_amd_erraturm is even worse. In fact, I can't see a single case where the origin code is something we really want to keep. I still don't understand the complaint about 'c' as an identifier. ~Andrew
