[v1] misra: add deviation for MISRA C Rule 11.3

[PATCH] misra: add deviation for MISRA C Rule 11.3

Posted by Dmytro Prokopchuk1 2 months, 1 week ago

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@epam.com>
---
Test CI pipeline:
https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/1992968166
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 8 ++++++++
 automation/eclair_analysis/ECLAIR/monitored.ecl  | 1 +
 docs/misra/deviations.rst                        | 8 ++++++++
 3 files changed, 17 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 7f3fd35a33..3e595e3a8c 100644
--- 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
+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."
+-config=MC3A2.R11.3,reports+={safe,"any_area(any_loc(any_exp(macro(^container_of$))))"}
+-doc_end
+
 -doc_begin="Conversions from and to integral types are safe, in the assumption that the target type has enough bits to store the value.
 See also Section \"4.7 Arrays and Pointers\" of \"GCC_MANUAL\""
 -config=MC3A2.R11.6,casts+={safe,
diff --git a/automation/eclair_analysis/ECLAIR/monitored.ecl b/automation/eclair_analysis/ECLAIR/monitored.ecl
index 72698b2eb1..abfc102d60 100644
--- 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
 -enable=MC3A2.R11.6
 -enable=MC3A2.R11.7
 -enable=MC3A2.R11.8
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index 2119066531..33b045a5a9 100644
--- 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
+       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.
+     - Tagged as `safe` for ECLAIR.
+
    * - R11.6
      - Conversions from and to integral types are safe, in the assumption that
        the target type has enough bits to store the value.
-- 
2.43.0

Re: [PATCH] misra: add deviation for MISRA C Rule 11.3

Posted by Jan Beulich 2 months, 1 week ago

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

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

Re: [PATCH] misra: add deviation for MISRA C Rule 11.3

Posted by Dmytro Prokopchuk1 2 months, 1 week ago


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

Re: [PATCH] misra: add deviation for MISRA C Rule 11.3

Posted by Jan Beulich 2 months, 1 week ago

On 21.08.2025 16:13, Dmytro Prokopchuk1 wrote:
> On 8/21/25 12:18, Jan Beulich wrote:
>> On 20.08.2025 09:17, Dmytro Prokopchuk1 wrote:
>>> --- 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.

Does it not, i.e. not even on the time it takes Eclair to do a full run?

> Jan, decision up to you (include into monitored.ecl or not).

For x86 I think the count is still too high. And no, it's not solely my
decision.

Jan

Re: [PATCH] misra: add deviation for MISRA C Rule 11.3

Posted by Dmytro Prokopchuk1 2 months, 1 week ago


On 8/21/25 17:32, Jan Beulich wrote:
> On 21.08.2025 16:13, Dmytro Prokopchuk1 wrote:
>> On 8/21/25 12:18, Jan Beulich wrote:
>>> On 20.08.2025 09:17, Dmytro Prokopchuk1 wrote:
>>>> --- 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.
> 
> Does it not, i.e. not even on the time it takes Eclair to do a full run?

Yes, scan time depends on number of enabled rules.
But I don't know the time values.

Dmytro.

> 
>> Jan, decision up to you (include into monitored.ecl or not).
> 
> For x86 I think the count is still too high. And no, it's not solely my
> decision.
> 
> Jan

Re: [PATCH] misra: add deviation for MISRA C Rule 11.3

Posted by Dmytro Prokopchuk1 2 months, 1 week ago


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

Re: [PATCH] misra: add deviation for MISRA C Rule 11.3

Posted by Nicola Vetrini 2 months, 1 week ago

On 2025-08-21 16:28, Dmytro Prokopchuk1 wrote:
> 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@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).
> 

I agree

> 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

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