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. -George
