[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] docs/misra: new rules addition
On 09/06/23 10:46, Jan Beulich wrote: 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. Typedefs being used this way can be deviated with tool configuration. Here is a list of candidates for that treatment: guest_intpte_t guest_l1e_t guest_l2e_t ret_ I am not sure about the latter. Please let me know if this is what you would prefer and possible additions to/removals from the above list. Kind regards, Roberto
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |