On 31.10.18 15:44, Markus Armbruster wrote: > 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? >
I'll have a look if something has to be done on that side. -- Thanks, David / dhildenb