3a86a0fa76
Right now, the semantics of next_list are complicated. The caller must: * call start_list * call next_list for each element *including the first* * on the first call to next_list, the second argument should point to NULL and the result is the head of the list. On subsequent calls, the second argument should point to the last node (last result of next_list) and next_list itself tacks the element at the tail of the list. This works for both input and output visitor, but having the visitor write memory when it is only reading the list is ugly. Plus, relying on *list to detect the first call is tricky and undocumented. We can initialize so->entry in next_list instead of start_list, leaving it NULL in start_list. This way next_list sees clearly whether it is on the first call---as a bonus, it discriminates the cases based on internal state of the visitor rather than external state. We can also pull the assignment of the list head from generated code up to next_list. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> |
||
---|---|---|
.. | ||
specs | ||
blkverify.txt | ||
bootindex.txt | ||
ccid.txt | ||
ich9-ehci-uhci.cfg | ||
libcacard.txt | ||
live-block-ops.txt | ||
memory.txt | ||
migration.txt | ||
qapi-code-gen.txt | ||
qdev-device-use.txt | ||
tracing.txt | ||
usb2.txt | ||
writing-qmp-commands.txt | ||
xen-save-devices-state.txt |