qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH v2 1/7] qapi: Allow decimal values


From: Eric Blake
Subject: Re: [Qemu-devel] [RFC PATCH v2 1/7] qapi: Allow decimal values
Date: Tue, 20 May 2014 09:11:51 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

On 05/20/2014 03:07 AM, Fam Zheng wrote:
> This allows giving decimal constants in the schema as expr.
> 
> Signed-off-by: Fam Zheng <address@hidden>
> ---
>  scripts/qapi.py | 22 ++++++++++++++++++++--
>  1 file changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/scripts/qapi.py b/scripts/qapi.py
> index 0265b40..4c945ad 100644
> --- a/scripts/qapi.py
> +++ b/scripts/qapi.py
> @@ -157,6 +157,21 @@ class QAPISchema:
>                          return
>                      else:
>                          string += ch
> +            elif self.tok in "-0123456789":
> +                val = self.tok
> +                while self.src[self.cursor] in "0123456789":
> +                    val += self.src[self.cursor]
> +                    self.cursor += 1
> +                try:
> +                    if val.startswith("0") and len(val) > 1:

This fails to diagnose '-0123' as invalid.  Which means your test case
in 3/7 is incomplete.

> +                        raise Exception("Leading zero for non-zero integer")

For the string "00", this message makes no sense.  You are properly
diagnosing that double 0 is not a valid JSON int, but it is also not a
"non-zero integer".  Maybe just "Leading zero not permitted for integer".

> +                    self.val = int(val)
> +                    if self.val > 0x7fffffffffffffffL or self.val < 
> -0x7fffffffffffffffL - 1:
> +                        raise Exception("Value too big")

Forces the user to use int64_t rather than allowing for uint64_t
defaults (if we have an unsigned value that defaults to anything larger
than INT64_MAX, it would have to be written in 2s-complement negative
form) - but that's okay with me (I really doubt we'd have any default in
that situation except possibly UINT64_MAX, but writing -1 for UINT64_MAX
doesn't feel too bad).

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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