Re: [XEN PATCH v2 4/4] x86/setup: address MISRA C:2012 Rule 5.3

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

On 07/08/2023 15:42, Jan Beulich wrote:
> On 07.08.2023 15:18, Nicola Vetrini wrote:
> > On 07/08/2023 15:05, Jan Beulich wrote:
> > > On 04.08.2023 10:03, Nicola Vetrini wrote:
> > > > The parameters renamed in the function declaration caused shadowing
> > > > with the homonymous variable in 'xen/common/efi/boot.c'. Renaming
> > > > them also addresses Rule 8.3:
> > > > "All declarations of an object or function shall use the same names
> > > > and type qualifiers".
> > > Can you explain to me how shadowing can happen in a declaration? I
> > > would focus on 8.3 here, and only mention the other name collision.
> > There's "static struct file __initdata kernel;" in
> > xen/common/efi/boot.c, which
> > is visible when the function is declared. Since renaming these 
> > parameter
> > names would
> > have been addressed by Federico for R8.3 anyway, my intention was to
> > address them both.
> I understand what you say, but your reply doesn't answer my question.
> Just to emphasize the important aspect: I could see the shadowing
> aspect if the _definition_ of construct_dom0() used "kernel". But I'm
> asking about declarations (the one here as well as in general): I
> can't see how any shadowing can occur without there being any code in
> the position of using any such variable / parameter. IOW if Eclair
> spits out 5.3 violations on declarations, I'm inclined to think it's
> wrong. (Because of 8.3 a violation there would then need dealing with
> anyway, but _only_ because of 8.3, if the definition is already okay.)
>
> Jan
The declaration itself is a scope and shadowing can happen, as in:

int x;
void f(int x, int arr[x]);

Now, the example is a bit contrived, but the fact that the rule does not 
list any
exception motivates this behaviour. In any case, I'll try to rephrase 
the commit message
to be less ambiguous.

--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)