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 <f...@redhat.com>
> ---
> 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
signature.asc
Description: OpenPGP digital signature
