MISRA C Rule 5.5 states that: "Identifiers shall
be distinct from macro names".

Update ECLAIR configuration to deviate clashes:
specify the macros that should be ignored.
Update deviations.rst and rules.rst accordingly.

Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
---
v1: https://patchew.org/Xen/7e1c381d6fab6d38bb2a5484d5fac5e863ba135f.1752689112.git.dmytro._5Fprokopchuk1@epam.com/

Changes in v2:
- changed Eclair configs (option '-reports' replaced with '-ignored_macros')
- updated deviations.rst
- updated rules.rst
- updated commit message

Test CI pipeline: https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/1948281147

MC3A2.R5.5 violations:
ARM - 0
X86 - 328
---
 .../eclair_analysis/ECLAIR/deviations.ecl     | 16 ++++++++++++
 docs/misra/deviations.rst                     | 25 +++++++++++++++++++
 docs/misra/rules.rst                          | 19 ++++++++++++++
 3 files changed, 60 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 483507e7b9..13e1511a7c 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -117,6 +117,22 @@ it defines would (in the common case) be already defined. Peer reviewed by the c
 -config=MC3A2.R5.5,reports+={deliberate, "any_area(decl(kind(function))||any_loc(macro(name(memcpy||memset||memmove))))&&any_area(any_loc(file(^xen/common/libelf/libelf-private\\.h$)))"}
 -doc_end
 
+-doc_begin="Clashes between bitops functions and macros names are deliberate.
+These macros are needed for input validation and error handling."
+-config=MC3A2.R5.5,ignored_macros+="name(__test_and_set_bit||__test_and_clear_bit||__test_and_change_bit||test_bit||set_bit||clear_bit||change_bit||test_and_set_bit||test_and_clear_bit||test_and_change_bit)"
+-doc_end
+
+-doc_begin="Clashes between 'pirq_cleanup_check' function and macro names are deliberate.
+The purpose is to ensure that the specific cleanup action
+('pirq_cleanup_check') is performed conditionally when the parameter 'event channel number' equals zero, otherwise it does nothing."
+-config=MC3A2.R5.5,ignored_macros+="name(pirq_cleanup_check)"
+-doc_end
+
+-doc_begin="Clashes between grant table functions and macros names are deliberate.
+These macros address differences in argument count during compile-time, effectively discarding unused parameters to avoid warnings or errors related to unused arguments."
+-config=MC3A2.R5.5,ignored_macros+="name(update_gnttab_par||parse_gnttab_limit)"
+-doc_end
+
 -doc_begin="The type \"ret_t\" is deliberately defined multiple times,
 depending on the guest."
 -config=MC3A2.R5.6,reports+={deliberate,"any_area(any_loc(text(^.*ret_t.*$)))"}
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index e78179fcb8..c6a0c084bf 100644
--- 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.
+
+   * - R5.5
+     - Clashes between 'pirq_cleanup_check' function and macro names are deliberate.
+       The purpose is to ensure that the specific cleanup action ('pirq_cleanup_check')
+       is performed conditionally when the parameter 'event channel number' equals
+       zero, otherwise it does nothing.
+       This approach simplifies the code, avoids redundant function call.
+     - Specified macro should be ignored.
+
+   * - R5.5
+     - Clashes between grant table functions and macros names are deliberate.
+       These macros address differences in argument count during compile-time,
+       effectively discarding unused parameters to avoid warnings or errors
+       related to unused arguments.
+     - Specified macro should be ignored.
+
    * - R5.6
      - The type ret_t is deliberately defined multiple times depending on the
        type of guest to service.
diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index 3e014a6298..3f288364b1 100644
--- a/docs/misra/rules.rst
+++ b/docs/misra/rules.rst
@@ -196,6 +196,25 @@ maintainers if you want to suggest a change.
            #define f(x, y) f(x, y)
            void f(int x, int y);
 
+       Clashes between bitops functions and macros names are allowed
+       when they are used for input validation and error handling.
+       Example::
+
+           static inline void set_bit(int nr, volatile void *addr)
+           {
+               asm volatile ( "lock btsl %1,%0"
+                              : "+m" (ADDR) : "Ir" (nr) : "memory");
+           }
+           #define set_bit(nr, addr) ({                            \
+               if ( bitop_bad_size(addr) ) __bitop_bad_size();     \
+               set_bit(nr, addr);                                  \
+           })
+
+       Clashes between 'pirq_cleanup_check' function and macro names
+       are allowed.
+
+       Clashes between grant table functions and macros names are allowed.
+
    * - `Rule 5.6 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_05_06.c>`_
      - Required
      - A typedef name shall be a unique identifier
-- 
2.43.0

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.

> +   * - R5.5
> +     - Clashes between 'pirq_cleanup_check' function and macro names are deliberate.
> +       The purpose is to ensure that the specific cleanup action ('pirq_cleanup_check')
> +       is performed conditionally when the parameter 'event channel number' equals
> +       zero, otherwise it does nothing.
> +       This approach simplifies the code, avoids redundant function call.
> +     - Specified macro should be ignored.

Here it's clear which macro is meant, but ...

> +   * - R5.5
> +     - Clashes between grant table functions and macros names are deliberate.
> +       These macros address differences in argument count during compile-time,
> +       effectively discarding unused parameters to avoid warnings or errors
> +       related to unused arguments.
> +     - Specified macro should be ignored.

... here it again isn't.

Jan

On 7/28/25 12: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.
> 
>> +   * - R5.5
>> +     - Clashes between 'pirq_cleanup_check' function and macro names are deliberate.
>> +       The purpose is to ensure that the specific cleanup action ('pirq_cleanup_check')
>> +       is performed conditionally when the parameter 'event channel number' equals
>> +       zero, otherwise it does nothing.
>> +       This approach simplifies the code, avoids redundant function call.
>> +     - Specified macro should be ignored.
> 
> Here it's clear which macro is meant, but ...
> 
>> +   * - R5.5
>> +     - Clashes between grant table functions and macros names are deliberate.
>> +       These macros address differences in argument count during compile-time,
>> +       effectively discarding unused parameters to avoid warnings or errors
>> +       related to unused arguments.
>> +     - Specified macro should be ignored.
> 
> ... here it again isn't.
> 
> Jan

Thanks!
I'll add macros names.

Dmytro

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.

>> +   * - R5.5
>> +     - Clashes between 'pirq_cleanup_check' function and macro names 
>> are deliberate.
>> +       The purpose is to ensure that the specific cleanup action 
>> ('pirq_cleanup_check')
>> +       is performed conditionally when the parameter 'event channel 
>> number' equals
>> +       zero, otherwise it does nothing.
>> +       This approach simplifies the code, avoids redundant function 
>> call.
>> +     - Specified macro should be ignored.
> 
> Here it's clear which macro is meant, but ...
> 
>> +   * - R5.5
>> +     - Clashes between grant table functions and macros names are 
>> deliberate.
>> +       These macros address differences in argument count during 
>> compile-time,
>> +       effectively discarding unused parameters to avoid warnings or 
>> errors
>> +       related to unused arguments.
>> +     - Specified macro should be ignored.
> 
> ... here it again isn't.
> 
> Jan

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253

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

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.

On 28.07.2025 14:28, Dmytro Prokopchuk1 wrote:
> 
> 
> 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?

And then change all use sites of the macro to those upper-case forms? When
everyone's used to using the lower-case ones?

Jan

On 7/28/25 16:15, Jan Beulich wrote:
> On 28.07.2025 14:28, Dmytro Prokopchuk1 wrote:
>>
>>
>> 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?
> 
> And then change all use sites of the macro to those upper-case forms?
Yes.
> When everyone's used to using the lower-case ones?
Well, user habits vs. Misra compliance, clear code.
I like second one.
Let me repeat.
I can prepare patch (it will touch many places in code base), and let 
maintainers decide what to do with it.

While patch with deviations will be like spare plan.

Jan, Andrew,
are you agree with this?

Dmytro.
> 
> Jan

On 28.07.2025 17:29, Dmytro Prokopchuk1 wrote:
> 
> 
> On 7/28/25 16:15, Jan Beulich wrote:
>> On 28.07.2025 14:28, Dmytro Prokopchuk1 wrote:
>>>
>>>
>>> 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?
>>
>> And then change all use sites of the macro to those upper-case forms?
> Yes.
>> When everyone's used to using the lower-case ones?
> Well, user habits vs. Misra compliance, clear code.
> I like second one.
> Let me repeat.
> I can prepare patch (it will touch many places in code base), and let 
> maintainers decide what to do with it.
> 
> While patch with deviations will be like spare plan.
> 
> Jan, Andrew,
> are you agree with this?

No, I object to the renaming you intend to do. I don't think it is a useful
use of anyone's time to make or review such a change.

Jan