Re: [PATCH 13/14] passthrough/PCI: rework (s,b,d,f) init of struct pci_dev

["Roger Pau Monné" <roger@xenproject.org>]

On Wed, Sep 02, 2026 at 02:53:58PM +0200, Jan Beulich wrote:
> On 02.09.2026 14:44, Roger Pau Monné wrote:
> > On Wed, Sep 02, 2026 at 08:36:27AM +0200, Jan Beulich wrote:
> >> Right now we're casting away const-ness, to initialize the individual
> >> elements despite the field(s) being declared const. Eclair validly
> >> recognizes this as a Misra rule 11.8 violation. Hide this by switching to
> >> the use of memcpy(), deriving the destination address from the (mutable)
> >> struct pci_dev * which we hold in hands.
> >>
> >> No functional change intended.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >> ---
> >> Subsequently we may want to further leverage the sbdf local variable we
> >> now have in the function. Yet of course the primary question is: Is this
> >> an okay game to play in the first place?
> > 
> > I've wondered the same, while this might be obfuscated enough for
> > Eclair to complain, aren't we still violating the spirit of the rule?
> 
> We do, but what do you do without dropping that "const" (which I'd really
> like to keep), and without C++ concepts of initialization?

Is it possible to "tag" this with a comment?  Noting we are aware of
the MISRA violation, but the result of the field being const outweigh
the violation.

At the end the memcpy() is also a violation, and hence is likely to
also be flagged by Eclair in the future - it might be best to simply
come clean and accept we have an intentional violation here.

Thanks, Roger.