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