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
