Re: [PATCH v5 60/62] qapi: expose integer signedness and width in introspection

[Markus Armbruster <armbru@redhat.com>]

Marc-André Lureau <marcandre.lureau@redhat.com> writes:

> Hi
>
> On Tue, Oct 13, 2026 at 5:56 PM Markus Armbruster <armbru@redhat.com> wrote:
>>
>> Marc-André Lureau <marcandre.lureau@redhat.com> 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.

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.

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.

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.

[...]