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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 02.09.2026 17:07, Roger Pau Monné wrote:
> 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@xxxxxxxx>
>>>> ---
>>>> 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.

Surely we could make up a SAF comment for this, just that SAF comments
aren't liked by everyone either (personally I consider them ugly, but
kind of tolerable).

Jan