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

Re: [PATCH] docs/misra: new rules addition


  • To: Roberto Bagnara <roberto.bagnara@xxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 9 Jun 2023 10:46:55 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=z3Z4MVVfumThxoDxqxipl3niLROoLu8PrxF0ZfFefZ4=; b=I2JNe3amJwgRUOD4VOXmzQr6tALwXLuKeOQRR7pwgMVSF9DIA+Rd3qH1vY0WqDqy0X7efAGG2tGcH2vNExK83Yhpz+lZ2yEswqiZ1bkgy4J7KqSAjGYc7QGwikeLpoCRHDCjyUnOfjjZCtvNSZSxpXrAv3b605EmtkrzuKWV6JLSmt/GbdfXbf9wcO3FiQIwBUzauvHnkaBcxwLGtPn3Sq8CgTL/GWD1wQVqpWkmqVaVRIWLxZKiJQSG/gYQ7Jk3pmGderezF+jAixdN07U94oEfP/OTdRAgjYk0Snwfz6GiQ9ITLQqn/wZCyIrflqdzZ6Hotclvo3IkROLiJOTyYw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kXoFrJZTsbhYe0/9NSH+0/Aq4egnRVW7JO8lA/YTFoXQf7qWocbnnQ4+NkI/cdPzzGJczE9cdx0FmDwyGX02SYdux8obgYvOBV2FuQ9+aGIl6N+VAMDhMhCCtS3/FLZT9k95PNR/1SSkKOURM2+IpALt767X0oQ9N823ohLmeBNM2ZqTIxqzok0B0NIRMl0lAXrBKujYxLXgwwiqWy7Q6cwYc6SwmZ6D0K3U4xdOH94sqqH4CtEz+zYIWVC6P3I8t4IWHAs3GOEfSZdo1vGkqHBD9lLBou0py3jnu1OYQB9/d2+8iVKGosTItlrFH49BoyvO0Jf4j6MdT0jia90srQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: julien@xxxxxxx, andrew.cooper3@xxxxxxxxxx, roger.pau@xxxxxxxxxx, bertrand.marquis@xxxxxxx, Stefano Stabellini <stefano.stabellini@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • Delivery-date: Fri, 09 Jun 2023 08:47:21 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 08.06.2023 13:02, Roberto Bagnara wrote:
> On 07/06/23 23:53, Stefano Stabellini wrote:
>> On Wed, 7 Jun 2023, Jan Beulich wrote:
>>>> +   * - `Rule 5.6 
>>>> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_05_06.c>`_
>>>> +     - Required
>>>> +     - A typedef name shall be a unique identifier
>>>> +     -
>>>
>>> Considering that the rule requires uniqueness across the entire code
>>> base (and hence precludes e.g. two functions having identically named
>>> local typedefs), I'm a little puzzled this was adopted. I for one
>>> question that a use like the one mentioned is really at risk of being
>>> confusing. Instead I think that the need to change at least one of
>>> the names is at risk of making the code less readable then, even if
>>> ever so slightly. (All of this said - I don't know if we have any
>>> violations of this rule.)
>>
>> I don't think we have many local typedefs and I think we have only few
>> violations if I remember right. I'll let Roberto confirm how many. This
>> rule was considered not a difficult rule (some difficult rules were
>> found, namely 2.1, 5.5 and 7.4.)
> 
> There currently are 30 violations for ARM64:
> 
> - some involve a typedef module_name (in the call it was said this should
>    be renamed module_name_t, which will solve the issue);
> - most concern repeated typedefs (UINT64 and similar) which are repeated
>    in xen/arch/arm/include/asm/arm64/efibind.h
>    and xen/include/acpi/actypes.h
> - ret_t and phys_addr_t are also redefined in a couple of places.
> 
> There are 90 violations for X86_64, for the same reasons, plus
> 
> - another set of typedefs for basic types (such as u8);
> - repeated typedefs for things like guest_l1e_t in the same header file:
> 
> xen/arch/x86/include/asm/guest_pt.h:60.39-60.49:
> for program `xen/.xen-syms.0', the identifier for typedef `guest_l1e_t' is 
> reused
> xen/arch/x86/include/asm/guest_pt.h:128.22-128.32:
> for program `xen/.xen-syms.0', the identifier for typedef `guest_l1e_t' is 
> reused
> 
> The indicated lines read as follows:
> 
> typedef struct { guest_intpte_t l1; } guest_l1e_t;
> typedef l1_pgentry_t guest_l1e_t;

So this is an example where I don't think we can sensibly do away with the
re-use of the same typedef name: We use it so we can build the same source
files multiple ways, dealing with different paging modes guests may be in.

Jan



 


Rackspace

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