[libvirt] FYI: qemu silently clipping large integers in JSON protocol
This thread may be of interest: http://lists.gnu.org/archive/html/qemu-devel/2011-05/threads.html#02162 Currently, qemu silently clips any JSON integer in the range 0x8000_0000_0000_0000 - 0xffff_ffff_ffff_ffff (all numbers in this range will be clipped to 0x7fff_ffff_ffff_ffff == LLONG_MAX). This basically could affect any libvirt code in this file which uses the "U:..." prefix as far as I can tell: http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_monitor_json.c;... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v
On Fri, May 20, 2011 at 08:20:33PM +0100, Richard W.M. Jones wrote:
This thread may be of interest:
http://lists.gnu.org/archive/html/qemu-devel/2011-05/threads.html#02162
Currently, qemu silently clips any JSON integer in the range 0x8000_0000_0000_0000 - 0xffff_ffff_ffff_ffff (all numbers in this range will be clipped to 0x7fff_ffff_ffff_ffff == LLONG_MAX).
This basically could affect any libvirt code in this file which uses the "U:..." prefix as far as I can tell:
http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_monitor_json.c;...
Reinventing the wheel allows to make the same mistakes multiple times :-) XPath Number IMHO got this right by referencing IEEE 754 but then XSLT made the fatal mistake of referencing the JDK 1.1 w.r.t. behaviour when serializing back (and reimplementing in C was a nightmare) Funny how people bashing technology N-1 manage to reproduce the same mistake or worse when designing N Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
participants (2)
-
Daniel Veillard -
Richard W.M. Jones