[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 05/12] x86/crash: address Misra 2.1 rule violation



On Thu, Sep 10, 2026 at 11:52:10AM +0200, Jan Beulich wrote:
> On 10.09.2026 11:30, Roger Pau Monné wrote:
> > On Thu, Sep 10, 2026 at 10:38:34AM +0200, Jan Beulich wrote:
> >> On 10.09.2026 09:49, Roger Pau Monné wrote:
> >>> On Fri, Aug 28, 2026 at 09:02:18AM +0200, Jan Beulich wrote:
> >>>> The use of unreachable(), when unreachability is visible to Eclair (and
> >>>> compilers), is deemed a violation. Drop the redundant statement.
> >>>
> >>> Urg, isn't that something that should be fixed in Eclair then?
> >>> Otherwise all the unreachable() calls in our codebase are likely to be
> >>> found by Eclair sooner or later, and will need to be removed.
> >>
> >> No, aiui most are covered by deviations. In particular ones in BUG() and
> >> ASSERT_UNREACHABLE().
> > 
> > Shouldn't this be a deviation then also?
> 
> Maybe, just that I had no good idea how to express such a deviation 
> (preferably
> without a SAF comment).
> 
> >  Maybe it would be helpful if
> > the commit message states why this is handled differently from other
> > unreachable() instances then.
> 
> I've added "..., , and the one here isn't covered by a deviation" to the first
> sentence. Will that suffice?

TBH, the handling of unreachable() feels inconsistent to me.  I don't
blame you for this, I know you are just trying to fix the remaining
issues.

I guess I will defer the change to someone more familiar with MISRA
and why some unreachable() usages are covered by deviations while
others aren't.

I think the point of adding something to the commit message is to
justify why this is removed vs a deviation being added.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.