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

[Eric Blake]

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).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature