Re: [Qemu-devel] [PATCH 04/21] qobject: add quint type

[Markus Armbruster]

Eric Blake <address@hidden> writes:

> On 03/11/2017 07:22 AM, Marc-André Lureau wrote:
>> The type is not used at all yet. Add some tests to exercice it.
>
> s/exercice/exercise/
>
> I wonder if we need this patch at all.
>
> I've been thinking about a possible alternative representation, such
> that a single QInt type can cover _both_ signed and unsigned types, by
> having QInt track a sign bit bool in addition to a uint64_t value.
>
> If the user passes in a value in the range [0, INT64_MAX], the number is
> representable in both uint64_t and int64_t. So the internal sign bit
> would be omitted, as in { value=v, sign=false }.  Input visitors can
> visit this value with both the 'uint64' and the 'int64' visitors, and
> output visitors will output the same value.
>
> If the user passes in a value in the range [-INT64_MAX-1, -1], the
> number is intended to be used as a negative signed number.  So the QInt
> representation would be the 2s complement representation, { value=-v,
> sign=true }.  On input, the uint64_t visitor would reject the value as
> out of range, the int64_t visitor would return the appropriate negative
> value, and the generic int visitor will return the uint64_t value.  On
> output, the number would be given the negative signed value
> representation in anything that stringizes the value.
>
> If the user passes in a value in the range [INT64_MAX+1, UINT64_MAX},
> the number is intended to be used as a large unsigned number. So the
> QInt representation would be { value=v, sign=false }.  On input, the
> uint64_t visitor would accept the value, the int64_t visitor would
> reject it as out of range, and the generic int visitor will return the
> uint64_t value.  On output, the number would be given the positive
> unsigned value representation in the stringized form.
>
> That way, you don't have to complicate the (already-awkward) type
> promotion rules of QFloat vs QInt with yet another scalar type.  The
> input parser becomes friendlier - you can either use generic 'int' when
> you want to allow the user to pass in either signed or unsigned values
> (important for back-compat, where callers like libvirt learned that only
> signed values worked even when large unsigned values were wanted); or
> the specific 'int64' and 'uint64' types to force proper ranges.
>
> It's definitely an alternative implementation to the one you pursued in
> your series, so maybe we should first figure out WHAT we want
> represented, before implementing something that will be more baggage
> than we want (you at least have the advantage of patches that are
> written; my idea of adding a sign bool to QInt is still just in the
> initial idea stage).

RFC 7159 gives implementations wide latitude on number representation
(this is one of the several reasons why JSON is a poor standard from an
interoperability point of view).  Our current representation effectively
is "if it fits into int64_t, use that, else double".  What we need is
something that can represent uint64_t exactly, too.

You say you've been thinking about extending QInt's range to cover
uint64_t.  I've been thinking even more radically: replace both QInt and
QFloat by QNumber.  This is how JSON *actually* works.

The new QNumber type provides constructors from double, int64_t and
uint64_t.  It also provides conversion functions to double, int64_t and
uint64_t.  The latter two can fail.

I'd expect these to be perfectly servicable for the visitors.

Code messing with QObject directly might become slightly more elaborate.
But such code should be minimized anyway.