On 03/18/2015 08:36 AM, Daniel P. Berrange wrote: > When parsing integer values, we only used 'long' data type > in the virConfValue struct. This is insufficiently large > to deal with things like guest memory sizes on 32-bit platforms > which are using PAE for addressing > 4 GB of RAM. > --- > daemon/libvirtd-config.c | 6 +-- > src/locking/lock_daemon_config.c | 4 +- > src/locking/lock_driver_lockd.c | 4 +- > src/locking/lock_driver_sanlock.c | 6 +-- > src/lxc/lxc_conf.c | 6 +-- > src/qemu/qemu_conf.c | 6 +-- > src/util/virconf.c | 22 ++++---- > src/util/virconf.h | 6 +-- > src/xenconfig/xen_common.c | 8 +-- > tests/Makefile.am | 5 ++ > tests/libvirtdconftest.c | 4 +- > tests/virconftest.c | 105 ++++++++++++++++++++++++++++++++++++++ > 12 files changed, 146 insertions(+), 36 deletions(-) > create mode 100644 tests/virconftest.c > Beyond the concept of typing in that many numbers which boggles the mind and eyes... A couple of notes: virConfParseLLong() - comment needs to be updated from "Parse one long int value" to "long long" virConfSaveValue() - should the "%llu" be separate from "%lld", since now we're talking memory values? That leads to the more general question/issue of whether we virConfParseValue() - Similarly, should the virConfParseLLong have a virConfParseULLong? Yeah - I know, hard to imagine typing that many digits *and* being correct! Need to spend a long time shaving yaks and counting hairs to get that large! testCorrupt() - The error message "invalid type: got string; expected unsigned long" (and just "long") - Should they change to "unsigned long long" and "long long" respectively? ACK - unless there's something someone believes "has" to fit within the LONG/ULONG space. John -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list