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

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

[Dmytro Prokopchuk1]

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.
No functional changes.

Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
---
Changes in v2:
- removed '-enable=MC3A2.R11.3' from the monitored.ecl file
- fixed typo: "Convesions" -> "Conversions"
- added parentheses for macros container_of() and offsetof()

Link to v1:
https://patchew.org/Xen/d6a8682c98880d66ea99f882520b3defda0e3fe0.1755672275.git.dmytro._5Fprokopchuk1@epam.com/
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 8 ++++++++
 docs/misra/deviations.rst                        | 8 ++++++++
 2 files changed, 16 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 7f3fd35a33..42b84429f0 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="Conversions 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/docs/misra/deviations.rst b/docs/misra/deviations.rst
index 2119066531..db9e09c3cb 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
+     - Conversions 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 v2] misra: add deviation for MISRA C Rule 11.3

[Jan Beulich]

On 24.08.2025 19:27, 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.

I may have said so before: This all reads okay to me, just that I'm unsure
it would actually be convincing to an assessor. The "provided that ..." is
a pretty strong requirement, which isn't overly hard to get wrong. Stefano,
Nicola - what's your take here?

Jan

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

[Dmytro Prokopchuk1]

On 8/25/25 13:23, Jan Beulich wrote:
> On 24.08.2025 19:27, 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.
> 
> I may have said so before: This all reads okay to me, just that I'm unsure
> it would actually be convincing to an assessor. The "provided that ..." is
> a pretty strong requirement, which isn't overly hard to get wrong. Stefano,
> Nicola - what's your take here?
> 
> Jan

Stefano, Nicola,

gentle reminder.

Dmytro.

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

[Nicola Vetrini]

On 2025-09-25 21:11, Dmytro Prokopchuk1 wrote:
> On 8/25/25 13:23, Jan Beulich wrote:
>> On 24.08.2025 19:27, 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.
>> 
>> I may have said so before: This all reads okay to me, just that I'm 
>> unsure
>> it would actually be convincing to an assessor. The "provided that 
>> ..." is
>> a pretty strong requirement, which isn't overly hard to get wrong. 
>> Stefano,
>> Nicola - what's your take here?
>> 
>> Jan
> 
> Stefano, Nicola,
> 
> gentle reminder.
> 
> Dmytro.

The fact that you can't guarantee that the pointer you receive is 
aligned was the main reason why I didn't already introduce such a 
deviation in the first place. Now, as Stefano pointed out unaligned 
accessed are largely ok on ARM and x86, with the exception on MMIO 
pointers (hard fault) and some niche cases in x86 which probably don't 
matter for Xen dealing with vectorized data types. So the crucial point 
(not just for this specific deviation) is ensuring that pointer are 
properly aligned when it matters, which in this case is the same as 
making sure that "ptr" indeed points to a struct member. What might be a 
convincing argument is to have sufficient testing and sanitizers (ASAN 
mostly helps here) to show that this assumption is met with some degree 
of confidence.

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