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.
>
>> --- 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
