Re: [PATCH v1] misra: add deviation of Rule 5.5

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.lira@xxxxxxx 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