[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Address MISRA C:2012 Rule 8.4
- To: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Mon, 7 Aug 2023 09:26:47 +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=dJu3C6ooQ2gGorMkv0ItusmU0mDmCTJKQYDF5xjDWOQ=; b=AMUreFfjVA17v7YqrAZemDnNIE8FkJl7nWSMXObAYaKSA7Aqx3ZUCwTQq1gxtXt/Oo+AvfxVZN6Lukh4KorceEmNAK8zo9ZlbTk+15a0WJc9gdfliHQzYAtlU4A9thGsGy07v1zwzUOGu6oROz3l92bCKyQ+zZ+RwSBHCVmf0muA3x2q27CVFmeO/5dxZSa3Q1iDH9MgIIbZ9hSWwSEROrCw59Xg8i4Z6fPvBbeIOS5elGeb/KDMtl1JKVc+8VFPgd7RTBnTjB3U9y/EwyC2NcbheyMoOoCUQKJUwvgSL5BxIC4KvzLb1QWoMlJ/nH9BSvNju5xljrOWlyLCQYjFWQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JCG3DgBb66QOLEioPB41q4iDcn2BD077fliNyj2Idh7FQaKONL+8R+KbWUj1ISVbf0YeG+B1HgZoOY0tugRBOGdojzKMcfesOq0LjdK5WhTucO9lPjigxTrzti5TWYO3RpDIKjdxiBhkDnrJOa56xijlAATRLxaYw7CFfdy1NEVqkhV24M6Ui/Mke16wCUbaX1eb9VgHC6oR+Wo4k36UAdSFvhlXyPEQSirEuWElMRMSWqZZMOzJPavJQR5ox19NJoiH6+mqmZWPPVzF+0LQC0aDJR1ETHKb1c8sseokZO+aQSq2rsH+l/Lz9KLEBut+xts4tn3na9NJUFuigWwITw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, xenia.ragiadakou@xxxxxxx, Ayan Kumar Halder <ayankuma@xxxxxxx>, consulting@xxxxxxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
- Delivery-date: Mon, 07 Aug 2023 07:27:00 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 04.08.2023 16:09, Nicola Vetrini wrote:
>>> 3. One possible resolution pattern is including 'acglobal.h' twice
>>> (either directly or indirectly trough acpi.h, if
>>> the latter does not cause other issues) like so:
>>>
>>> (assuming DEFINE_ACPI_GLOBALS is undefined here)
>>> #include "acglobal.h"
>>> #define DEFINE_ACPI_GLOBALS
>>> #include "acglobal.h"
>>>
>>> this way, the rule is followed properly, though it's not the
>>> prettiest
>>> pattern and also clashes with the objectives
>>> of D4.10 ("Precautions shall be taken in order to prevent the
>>> contents
>>> of a header file being included
>>> more than once"), but then a motivated exception is allowed there.
>>
>> Not really sure about this one.
>
> If you can tell me more about why that header is defined the way it is
> (i.e. why it's used twice with
> DEFINE_ACPI_GLOBALS #defined and the other times without), maybe we can
> come up
> with better alternatives.
The "Why?" question can only be answered by the ACPICA folks who originally
made it like this. Linux inherited the file from there, and we inherited it
from Linux. See also Stefano's reply on the matter. My guess is that the
goal was to have just a single place that needs changing (besides consumer
sites, where changes may or may not be necessary) if the type of a variable
needs to be adjusted.
Jan
|
