[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>
  • Date: Thu, 21 Aug 2025 14:28:21 +0000
  • Accept-language: en-US, uk-UA, ru-RU
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2pBSA7ptOM59xle2qOeWezWcB6iRprCVAaj5xGEaFcY=; b=N2UGrCYyNKK5ITy0hboB7grgwdsHX+hEGvIOmB9QfoGC0Kgi+Hlb0byEP+K8BH8EsSrSFODL5/FCZw4Gtr4Mnb0LQ+j95awbHZYZvm5/0VZ5GY2ol1S/+hx0MAPXxhOKOM11tKYzqHHk1a417PgZpeWtpW4lAzRhLa6AH3x2Fmlc1uRl2J1I8jzjpK/V+ggginxi2CWRO83BExT4xWs9IFzJbDNNLsmd2EhMxdlDdVESNVDapQVIU4Dr4DP/X7LWGWsMUivrb7FkNSB7JuIavHzIJ7d3YrYXgyt0pfFFCannN8QLMpbcODR0IidJccQOiVXOAg5vRyuJzXpdogWlTQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SLB/rfLhp1qIg5vsJXHUd6WmKogkr82FOnwiTFsukVLkhS53lg/Ppl0NpOgpaqY6ywafELCkJ2ucNgPqLYATNlJVD653GiEixNXD5kLlKMoKhdh8K0u+UP0ekqWYIRmtuVD28IZ0mb64Yr0Fzv7DppGPdy2AUlTrYqr4XWnweSYEs9E3pWDsK+mqE4hhcqxF9FPA5S8uMWOKIzz0TLbbk2QbVxr7WAQjP1nogOMUyH2LrAZV6D+epKmPBFkQ/GDC6xwk9zOc/Xlkz69SZoV2uh2LIHzN8gYl1dNlfAxoo8l2O0l85qiupLz19rlplDInxmWcUgVO2qcUkOGcQYlLdg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
  • Cc: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>, Doug Goldstein <cardoe@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 21 Aug 2025 14:28:29 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHcEaKMMDydbZiTjE+UNGKddouDNbRs1fAAgABSSoCAAAQwAA==
  • Thread-topic: [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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.