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

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

On 2023-12-12 15:01, Jan Beulich wrote:
> 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
Just a naming coincidence, there aren't any attributes involved. No 
change to Xen code is needed.
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)