Re: [XEN PATCH 5/7] xen/arm: v{cp,sys}reg: address violations of MISRA C:2012 Rule 16.3

[Federico Serafini <federico.serafini@xxxxxxxxxxx>]

On 20/12/23 12:55, Jan Beulich wrote:
> On 20.12.2023 12:48, Julien Grall wrote:
> > On 20/12/2023 11:03, Federico Serafini wrote:
> > > --- a/xen/arch/arm/arm64/vsysreg.c
> > > +++ b/xen/arch/arm/arm64/vsysreg.c
> > > @@ -210,8 +210,8 @@ void do_sysreg(struct cpu_user_regs *regs,
> > >            /* RO at EL0. RAZ/WI at EL1 */
> > >            if ( regs_mode_is_user(regs) )
> > >                return handle_ro_raz(regs, regidx, hsr.sysreg.read, hsr, 0);
> > > -        else
> > > -            return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
> > > +
> > > +        return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
> > I don't 100% like this change (mostly because I find if/else clearer
> > here).
> While (it doesn't matter here) my view on this is different, I'm still
> puzzled why the tool would complain / why a change here is necessary.
> It is not _one_ return statement, but there's still (and obviously) no
> way of falling through.
The tool is configurable:
if you prefer deviate these cases instead of refactoring the code
I can update the configuration.


> > But I have the feeling any other solution would probably be
> > worse.
> Use the conditional operator?
>
> Jan
>
> > So:
> >
> > Acked-by: Julien Grall <jgrall@xxxxxxxxxx>
> >
> > Cheers,
--
Federico Serafini, M.Sc.

Software Engineer, BUGSENG (http://bugseng.com)