Hi On Wed, Oct 14, 2026 at 10:06 AM Markus Armbruster <[email protected]> wrote: > > Marc-André Lureau <[email protected]> writes: > > > Hi > > > > On Tue, Oct 13, 2026 at 5:56 PM Markus Armbruster <[email protected]> wrote: > >> > >> Marc-André Lureau <[email protected]> writes: > >> > >> > Integer built-in types are currently canonicalized to "int" in > >> > query-qmp-schema. Consequently, clients cannot distinguish types such > >> > as int8, uint64, and size, even though they accept different ranges. > >> > >> This is by design. > >> > >> Width and signedness are an implementation detail. We can change them > >> freely without affecting syntactic compatibility of the wire protocol. > >> > >> If we expose them, we can't anymore, and docs/devel/qapi-code-gen.rst > >> section "Compatibility considerations" needs an update. > >> > >> Why would this be useful? Knowing width and signedness narrows down the > >> possible values some, but it need not be tight. > > > > Well, this was just a first step toward a better introspection support > > for constaints. I understand the wire format is just json int, but we > > may want to express ranges, enumeration of valid values, alignment, > > string format etc.. Exposing signdness and width is the basics, and > > establishes a pattern for carrying type-level metadata beyond just > > "json-type". This enable clients to do proper validation and UI > > generation without knowledge of commands and internals. > > Let's assume for the sake of the argument we want to do this. > > How to best communicate constraints to clients is not obvious. Not > least because our idea on what constraints exactly we want to > communicate is little more than hand-waving so far. > > Constraints on acceptable values for integer types could be encoded in > type names. This is one way to communicate constraints. Whether it's a > good way is not obvious. But let's think about it some more.y
The patch doesn't use type names to communicate constraints. They are just identifiers - the spec already says they're meaningless strings. Constraints are communicated with the "integer" member (signed/bits), purely additive to SchemaInfoBuiltin. > > We'd move from the single type name "int" to multiple ones. In theory, > existing clients use type name "int" only to lookup the SchemaInfo, then > recognize "meta-type": "builtin", "json-type": "int". Splitting up > built-in type "int" into several types does not affect such clients as > long as the @json-type value remains the same. In practice, Hyrum's law > applies, and we'd have to work with client developers to make sure we're > not breaking existing clients. I don't understand how that could confuse existing clients, it should be a compatible change. > > Signedness and width are a crude approximation of the actual > constraints. I doubt it's useful by itself, and I'm unwilling to commit > to a way to communicate constraints just for that. It's useful to do client-side input validation, and present appropriate UI Again, this is the foundation, width and signedness are inherent properties. Future constraint systems (explicit ranges, alignment etc) would naturally extend SchemaInfoBuiltin. The "integer" member doesn't conflict with any design direction for richer additions. > Fortunately, this patch is only losely connected to what your series is > about, namely to "associate properties with QAPI schema types". We can > simply drop it. If you'd like to work on communicating constraints, we > can talk about scope and interface design separately. > > [...] > >
