[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XEN PATCH v2] xen/hypercalls: address violations of MISRA C:2012 Rule 8.3
- To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Mon, 28 Aug 2023 08:35:41 +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=Rk2HkhIJEUeZ69LdkQcNPRj2Op+2hDRrzI6oq+Rd9uo=; b=D87cCrqn8BNFB0vgsN6apzYAC290D0wwvjyEjEr0JoHucv4lTyroV6WvzolQFtHI47VApoZMBXIarJyPqR8A+qfk/rqbkkO+LCt5BreRzTTRDO0c0OdXUG0NniafgDkKhCT76iIQRtr+8ezU54/tpADRiMWsMXIUwOYV91ikMgyPwwYYTLma73di+xmEe5yP8OS73yKwQQwshc5Wp28OXdrH+/mbUnfyW2UjKjuUflmNHKCi9+4fvA3/W4LqfsdV0g2JcKOGu/T/AS6zIuMleqnUqql8/7aX7H8u8sC6ykGVFK8P4+3w2j7x9N954IJwxu4tc8P7a7OPs+cXOdPKFg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TK9u/igq+f+RUVtNaxL17IhIcoO1xAPa7Wqiu0KdD/Kfr5ggZzbDJgsAlZE3vawp7D17w24+6pPCvsPNkfsOhWIiWWfyZbjL4sr5JYNC+Rcgr49jr7u/oeQ+ZSmPSODFY3TOhUWFp+iYrIRvVIAsoFv4/JvSFJuJ5lPlQaSIQ46KQ0QJwxvIQ14KlLJ6f0nyH53mLAuSwk41q2IwzZHIjMqmOp3oCObnKPAQk2Of42KpgLMnoSxB4dsY7VfdXWF/3CVXmNvOzX+SUOSVzhDtGazyKhU/FnLGlS5yJDU2SE72uRrtZ797aesxI3p+k6k5dC0LR4yrN2r5PY2oZekScQ==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Federico Serafini <federico.serafini@xxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, consulting@xxxxxxxxxxx, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, roger.pau@xxxxxxxxxx
- Delivery-date: Mon, 28 Aug 2023 06:35:51 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 26.08.2023 00:21, Stefano Stabellini wrote:
> Coming to unsigned int, it should be 32-bit on all supported arches,
But this isn't a requirement, even if we're using "unsigned int" in the
C declarations / definitions: If "unsigned int" was wider, all we'd
demand is that hypercall entry code (likely written in assembly anyway)
zero-extend incoming values suitably to fit whatever "unsigned int" is.
Which is no different to Andrew (aiui) suggesting to use "unsigned
long" instead: That'll too require suitable zero-extension up front.
> so
> it is down to consistency, which is a bit arbitrary. We have quite a
> good mix of unsigned int and uint32_t in hypercall-defs.c, specifically:
> 10 uint32_t
> 32 unsigned int
>
> By popular vote, I would go with unsigned int. So, I would keep the
> patch as is.
Well, I wouldn't quite say "as is": It clearly wants splitting for the
two entirely unrelated changes. Then the uncontroversial part can go
in right away, while we settle on the controversial aspect.
As to "popular vote" - ./CODING_STYLE also matters here, and favors
non-fixed-width types over fixed-width ones. And as per above imo
there's no technical reason to use fixed-width types here. Yet I
understand Andrew takes a different perspective ...
Jan
|
