Re: [XEN PATCH 7/7] x86/xstate: move BUILD_BUG_ON to address MISRA C:2012 Rule 2.1

From: Jan Beulich <jbeulich@suse.com>
To: Nicola Vetrini <nicola.vetrini@bugseng.com>
Cc: consulting@bugseng.com,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>,
	xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH 7/7] x86/xstate: move BUILD_BUG_ON to address MISRA C:2012 Rule 2.1
Date: Tue, 12 Dec 2023 15:01:31 +0100	[thread overview]
Message-ID: <c2679666-9cd6-45aa-a222-82a589247ea2@suse.com> (raw)
In-Reply-To: <06787876c18401f7adbfb23f7f91ee84@bugseng.com>

On 12.12.2023 14:38, Nicola Vetrini wrote:
> On 2023-12-12 11:07, Jan Beulich wrote:
>> On 12.12.2023 11:04, Jan Beulich wrote:
>>> On 11.12.2023 11:30, Nicola Vetrini wrote:
>>>> The string literal inside the expansion of BUILD_BUG_ON is considered
>>>> unreachable code; however, such statement can be moved earlier
>>>> with no functional change.
>>>
>>> First: Why is this deemed dead code in its present position, but okay 
>>> when
>>> moved? Second: While moving is indeed no functional change (really
>>> BUILD_BUG_ON() can be moved about anywhere, for not producing any code 
>>> in
>>> the final binary), it removes the connection between it and the 
>>> respective
>>> asm() (where %z would have been nice to use).
>>
>> Oh, and third: Which string literal? I expect you're not building with
>> an ancient compiler, so it got to be
>>
>> #define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!(" #cond ")"); 
>> })
>>
>> which you see in use. Yet that string literal isn't "code" or "data", 
>> but
>> an argument to _Static_assert(). Is Eclair perhaps not properly aware 
>> of
>> _Static_assert()?
> 
> On further inspection, this should have fallen into the deviation for 
> pure decls. This patch can be dropped, we'll adjust this inside ECLAIR.

What's the connection to "pure" here? Or are you merely piggybacking on
that attribute for this non-function?

Jan