On Fri, 15 Mar 2024, George Dunlap wrote: > On Fri, Mar 15, 2024 at 2:13 PM Jan Beulich <[email protected]> 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 <[email protected]> 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.
