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

Reply via email to