Re: [PATCH] do_multicall and MISRA Rule 8.3\

[George Dunlap <george.dunlap@xxxxxxxxx>]

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.

 -George