On 26.08.2023 00:21, Stefano Stabellini wrote: > Coming to unsigned int, it should be 32-bit on all supported arches,
But this isn't a requirement, even if we're using "unsigned int" in the C declarations / definitions: If "unsigned int" was wider, all we'd demand is that hypercall entry code (likely written in assembly anyway) zero-extend incoming values suitably to fit whatever "unsigned int" is. Which is no different to Andrew (aiui) suggesting to use "unsigned long" instead: That'll too require suitable zero-extension up front. > so > it is down to consistency, which is a bit arbitrary. We have quite a > good mix of unsigned int and uint32_t in hypercall-defs.c, specifically: > 10 uint32_t > 32 unsigned int > > By popular vote, I would go with unsigned int. So, I would keep the > patch as is. Well, I wouldn't quite say "as is": It clearly wants splitting for the two entirely unrelated changes. Then the uncontroversial part can go in right away, while we settle on the controversial aspect. As to "popular vote" - ./CODING_STYLE also matters here, and favors non-fixed-width types over fixed-width ones. And as per above imo there's no technical reason to use fixed-width types here. Yet I understand Andrew takes a different perspective ... Jan