Re: [PATCH v2] misra: add deviations of MISRA C Rule 5.5

[Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>]

On 7/28/25 13:59, Andrew Cooper wrote:
> On 28/07/2025 11:38 am, Nicola Vetrini wrote:
>> On 2025-07-28 11:36, Jan Beulich wrote:
>>> On 25.07.2025 18:24, Dmytro Prokopchuk1 wrote:
>>>> --- a/docs/misra/deviations.rst
>>>> +++ b/docs/misra/deviations.rst
>>>> @@ -142,6 +142,31 @@ Deviations related to MISRA C:2012 Rules:
>>>>          memmove.
>>>>        - Tagged as `deliberate` for ECLAIR.
>>>>
>>>> +   * - R5.5
>>>> +     - Clashes between bitops functions and macros names are
>>>> deliberate and are
>>>> +       needed for input validation and error handling, ensures that
>>>> the size of
>>>> +       the object being pointed to by 'addr' meets the minimum
>>>> requirements for
>>>> +       the bit operation, preventing unsafe operations on
>>>> improperly sized data
>>>> +       types that could lead to undefined behavior or memory
>>>> corruption.
>>>> +       The macros encapsulate this conditional logic into a single,
>>>> reusable form;
>>>> +       which simplifies the code, avoids redundant function call.
>>>> +     - Specified macros should be ignored.
>>>
>>> At the risk of going too far with nitpicking: Who are "specified
>>> macros" here? The
>>> text doesn't mention any names. In fact, the way it's written it
>>> could be taken to
>>> mean all macros there, including any that are yet to be added. I
>>> don't think such
>>> is appropriate for a deviation.
>>>
>>
>> I agree with Jan here. Either you make a single deviation record
>> encompassing all deviated macros or you have one per deviation (e.g.,
>> one for irq.h, one for grant_table.h and one for bitops.h) listing the
>> macros that are considered. For bitops it might be a concern the
>> actual functions going out of sync, but in that case you could just
>> spell out the deviation and say "all pairs functions/macros in file
>> <file> that are defined using the same identifier" or something similar.
> 
> Honestly, while these examples might be deliberate, they're also bad code.
> 
> I do not intent to let the bitops aliases survive the cleanup/fixes I
> have planned, but I also don't have any idea when I'll get to that work.
> 
> What we really want to express is "these are begrudgingly accepted in
> the short term.  don't copy this pattern, and if you can fix it, please do".
> 
> ~Andrew

Hi Andrew!

Perhaps I can try to fix these names clashes.

For clarity.
I would like to rename macros names with capital letters.
Like this:
-#define __test_and_change_bit(nr, addr) ({              \
+#define TEST_AND_CHANGE_BIT(nr, addr) ({              \
      if ( bitop_bad_size(addr) ) __bitop_bad_size();     \
      __test_and_change_bit(nr, addr);                    \
  })

Are you OK with such approach?

Or did you mean other?

Dmytro.