|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] misra: add deviation for MISRA C Rule 11.3
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_prokopchuk1@xxxxxxxx>
>>
>> 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |