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