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