qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH v4 2/5] qapi: Add qobject_is_equal(


From: Markus Armbruster
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH v4 2/5] qapi: Add qobject_is_equal()
Date: Mon, 14 Aug 2017 11:07:11 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Max Reitz <address@hidden> writes:

> On 2017-07-11 13:33, Markus Armbruster wrote:
>> Max Reitz <address@hidden> writes:
>> 
>>> First of all, OK, you don't want QNum(42.0) to equal QNum(42) at all (at
>>> least not right now and in the foreseeable future).
>>> You're the maintainer, so you decide, so I'll go along with it. :-)
>>>
>>> Now, let's follow up with my therefore rather useless commentary:
>>>
>>> (Feel free to disregard, because honestly, I can see how replying to
>>> most of the points I'm asking isn't really worth the time...)
>> 
>> When I use the authority entrusted to maintainers, I feel obliged to at
>> least explain my reasoning.  Besides, putting my reasoning in words
>> tends to lead me to new insights.
>
> And I am indeed very grateful for that. :-)
>
>>> On 2017-07-10 11:17, Markus Armbruster wrote:
>>>> Max Reitz <address@hidden> writes:
>>>>
>>>>> On 2017-07-06 16:30, Markus Armbruster wrote:
>
> [...]
>
>>>> The only way to add unsigned integers without breaking QMP compatibility
>>>> is to make them interchangeable with signed integers.  That doesn't mean
>>>> you get to make floating-point numbers interchangeable with integers
>>>> now.
>>>
>>> Again, begs the question why QNum covers floating point numbers then and
>>> why this very fact is not documented in qnum.c.
>> 
>> What kind of documentation would you like to see?
>
> It would be good to note that the QNum type is not meant to be a
> completely uniform way to handle JSON numbers (e.g. if the user provides
> something with a decimal point but you need an integer, QNum will not do
> that conversion for you).
>
> It is (English indirect speech is broken badly) just meant to
> encapsulate the different variants a number can be represented in, but
> you're still generally supposed to read it out the way it was put in
> (exceptions apply, see signed/unsigned and qnum_get_double()).

Can we distill this into text that could become an actual patch?  Let me
try.

    QNum encapsulates how our dialect of JSON fills in the blanks left
    by the JSON specification (RFC 7159) regarding numbers.

    Conceptually, we treat number as an abstract type with three
    concrete subtypes: floating-point, signed integer, unsigned integer.
    QNum implements this a discriminated union of double, int64_t,
    uint64_t.

    The JSON parser picks the subtype as follows.  If the number has a
    decimal point or an exponent, it is floating-point.  Else if it fits
    into int64_t, it's signed integer.  Else if it first into uint64_t,
    it's unsigned integer.  Else it's floating-point.

    Any number can serve as double: qnum_get_double() converts under the
    hood.

    An integer can serve as signed / unsigned integer as long as it is
    in range: qnum_get_try_int() / qnum_get_try_uint() check range and
    convert under the hood.

What do you think?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]