On 8/21/25 17:13, Dmytro Prokopchuk wrote:
> 
> 
> On 8/21/25 12:18, Jan Beulich wrote:
>> On 20.08.2025 09:17, Dmytro Prokopchuk1 wrote:
>>> MISRA C Rule 11.3 states: "A cast shall not be performed between a 
>>> pointer
>>> to object type and a pointer to a different object type."
>>>
>>> Violations of this rule arise due to the 'container_of' macro, which 
>>> casts
>>> a member of a structure to its containing structure:
>>>      container_of(ptr, type, member) ({                             \
>>>             typeof_field(type, member) *__mptr = (ptr);             \
>>>             (type *)( (char *)__mptr - offsetof(type,member) );})
>>>
>>> The 'container_of' macro is safe because it relies on the 
>>> standardized and
>>> well-defined 'offsetof' macro to calculate the memory address of the
>>> containing structure, while assuming proper alignment and ensuring no
>>> undefined behavior, provided that the input pointer is valid and 
>>> points to
>>> the specified member.
>>>
>>> Configure Eclair to suppress violation reports related to 'container_of
>>> macro. Update 'deviations.rst' file accordingly. Add Rule 11.3 to the
>>> monitored list.
>>> No functional changes.
>>>
>>> Signed-off-by: Dmytro Prokopchuk <dmytro_prokopch...@epam.com>
>>
>> Looks largely okay; just one nit and a question:
>>
>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> @@ -403,6 +403,14 @@ because the semantics of the 'noreturn' 
>>> attribute do not alter the calling conve
>>>   }
>>>   -doc_end
>>> +-doc_begin="Convesions in the 'container_of' macro are safe because 
>>> it relies on
>>
>> "Conversions" (also in deviations.rst)
>>
>>> --- a/automation/eclair_analysis/ECLAIR/monitored.ecl
>>> +++ b/automation/eclair_analysis/ECLAIR/monitored.ecl
>>> @@ -45,6 +45,7 @@
>>>   -enable=MC3A2.R10.2
>>>   -enable=MC3A2.R11.1
>>>   -enable=MC3A2.R11.2
>>> +-enable=MC3A2.R11.3
>>
>> While the description mentions this change, it doesn't say why (e.g. "no
>> violations left" or "only this and that violation left" or some such).
> ARM:  813V ->   16V
> X86: 1422V -> 1035V
> 
> Looks OK for ARM (to be added in the monitoring list), but X86...
> Anyway the number of reported errors has no side effect.
> 
> Jan, decision up to you (include into monitored.ecl or not).
> 
> Dmytro.

Actually, better way is to remove '-enable=MC3A2.R11.3' from the 
monitored.ecl file and create separate patch (in future).

Dmytro.

>>
>>> --- a/docs/misra/deviations.rst
>>> +++ b/docs/misra/deviations.rst
>>> @@ -393,6 +393,14 @@ Deviations related to MISRA C:2012 Rules:
>>>          (i.e., less strict) alignment requirement are safe.
>>>        - Tagged as `safe` for ECLAIR.
>>> +   * - R11.3
>>> +     - Convesions in the 'container_of' macro are safe because it 
>>> relies on
>>> +       the standardized and well-defined 'offsetof' macro to 
>>> calculate the memory
>>
>> Actually another nit: Here as well as in the description, it would be 
>> nice
>> to add parentheses, so indicate the function-ness of both macros (i.e.
>> container_of() and offsetof()).
>>
>> Jan

Reply via email to