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