Markus Armbruster <arm...@redhat.com> writes: > David Hildenbrand <da...@redhat.com> writes: > >> Right now, we parse uint64_t values just like int64_t values, resulting >> in negative values getting accepted and certain valid large numbers only >> being representable as negative numbers. Also, reported errors indicate >> that an int64_t is expected. >> >> Parse uin64_t separately. We don't have to worry about ranges. > > The commit message should mention *why* we don't we have to worry about > ranges. > >> >> E.g. we can now also specify >> -device nvdimm,memdev=mem1,id=nv1,addr=0xFFFFFFFFC0000000 >> Instead of only going via negative values >> -device nvdimm,memdev=mem1,id=nv1,addr=-0x40000000 >> >> Resulting in the same values >> >> (qemu) info memory-devices >> Memory device [nvdimm]: "nv1" >> addr: 0xffffffffc0000000 >> slot: 0 >> node: 0 >> > > Suggest to mention this makes the string-input-visitor catch up with the > qobject-input-visitor, which got changed similarly in commit > 5923f85fb82.
One more thing: the qobject-input-visitor change also updated the corresponding output visitor. Shouldn't we do the same here?
