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 <jbeul...@suse.com> 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. >>>> >>>> As with any not sufficiently clear statement, that's certainly true here, >>>> too. Yet if we try to give as wide meaning as possible to "a fixed width >>>> quantity is meant", there's basically no restriction on use of fixed width >>>> types because everyone can just say "but I mean a fixed width quantity >>>> here". I think the earlier sentence needs taking with higher priority, >>>> i.e. if a basic type does for the purpose, that's what should be used. The >>>> 2nd sentence then only tries to further clarify what the 1st means. >>> >>> Come, now. There are lots of situations where we just need some sort >>> of number, and there's no real need to worry about the exact size. >>> There are other situations, where we mean "whatever covers the whole >>> address space" or the like, where it makes sense to have something >>> like "unsigned long", which changes size, but in predictable and >>> useful ways. There are other situations, like when talking over an >>> API to code which may be compiled by a different compiler, or may be >>> running in a different processor mode, where we want to be more >>> specific, and set an exact number of bits. >>> >>> Should we use uint32_t for random loop variables? Pretty clearly >>> "No". Should we use uint32_t for the C entry of a hypercall, even >>> though the assembly code allegedly makes that unnecessary? At least >>> two core maintainers think "maybe just to be safe". That's hardly a >>> slippery slope of "anyone can say anything". >>> >>> 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. Jan
