Re: [PATCH] do_multicall and MISRA Rule 8.3\

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 15 Mar 2024, George Dunlap wrote:
> On Fri, Mar 15, 2024 at 2:13 PM Jan Beulich <jbeulich@xxxxxxxx> wrote:
> >
> > On 15.03.2024 14:55, Julien Grall wrote:
> > > Hi Jan,
> > >
> > > On 15/03/2024 13:24, Jan Beulich wrote:
> > >> On 15.03.2024 13:17, George Dunlap wrote:
> > >>> On Fri, Mar 15, 2024 at 11:57 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
> > >>>>> It sounds like Andy and Stefano feel like this is a situation where "a
> > >>>>> fixed width quantity is meant"; absent any further guidance from the
> > >>>>> CODING_STYLE about when fixed widths should or should not be used, I
> > >>>>> don't think this change would be a violation of CODING_STYLE.
> [snip]
> > >>> Other than "it's in CODING_STYLE", and "it's not really necessary
> > >>> because it's ensured in the assembly code", you haven't advanced a
> > >>> single reason why "uint32_t" is problematic.
> > >>
> > >> And it isn't, I never said it would be. But if we set rules for
> > >> ourselves, why would we take the first opportunity to not respect them?
> > >
> > > I am a bit confused. Reading through the thread you seem to agree that
> > > the written rules are respected here. So what rules are you talking about?
> >
> > What was proposed is use of a fixed width type where according to my
> > reading ./CODING_STYLE says it shouldn't be used.
> 
> This conversation is starting to get frustrating.  That's simply not
> what it says, and I pointed that out just a few messages ago.
> 
> To reiterate:The text says fixed-width types are OK when a fixed-width
> quantity is "meant"; and that in this case, Stefano and Andy "mean" to
> use a fixed-width quantity.  The implied subtext of that sentence
> could be, "Don't use fixed width types unless there's a good reason to
> use a fixed width", and both Andy and Stefano think there's a good
> reason.  This argument you haven't really addressed at all, except
> with a specious "slippery slope" argument meant to nullify the
> exception; and now you attempt to simply ignore.
> 
> I venture to assert that for most people, the rules are a means to an
> end: That end being code which is correct, robust, fast, easy to
> write, maintain, debug, and review patches for.  What I agreed to,
> when I accepted this patch, was that *in general* we would avoid using
> fixed-width types; but that there were cases where doing so made
> sense.  Some of those were discussed in the thread above.
> 
> Andy and Stefano have already put forward reasons why they think a
> fixed-width type would be better here, which are related to "end
> goals": namely, more robust and easy to maintain code.  When I asked
> what "end goals" would be negatively impacted by using a fixed-width
> type, you explicitly said that there were none!  That the *only*
> reason you're continuing to argue is that we have a document somewhere
> that says we should -- a document which explicitly acknowledges that
> there will be exceptions!
> 
> The ideal response would have been to lay out a reasonably
> comprehensive set of criteria for when to use basic types, when to use
> fixed-width types, and how each criteria advanced the end goals of a
> better codebase.  A sufficient response would have been to lay out
> reasons why "better codebase", in this instance, tilts towards using a
> basic type rather than a fixed-width type.
> 
> Saying "That's what the rules say", without motivating it by
> explaining how it connects to a better codebase, is just not a helpful
> response; and making that argument after it's been pointed out that
> that is *not* what the rules say is even worse.

Thanks George for taking the time to write all of the above.

Let's please move forward with this patch.