From 3a86a0fa76b5103a122b6e817b3827b2837f4956 Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Thu, 22 Mar 2012 22:38:40 +0100 Subject: qapi: untangle next_list 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 Reviewed-by: Michael Roth Signed-off-by: Luiz Capitulino --- docs/qapi-code-gen.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs') diff --git a/docs/qapi-code-gen.txt b/docs/qapi-code-gen.txt index 5831e37..ad11767 100644 --- a/docs/qapi-code-gen.txt +++ b/docs/qapi-code-gen.txt @@ -194,11 +194,11 @@ Example: void visit_type_UserDefOneList(Visitor *m, UserDefOneList ** obj, const char *name, Error **errp) { - GenericList *i; + GenericList *i, **prev = (GenericList **)obj; visit_start_list(m, name, errp); - for (i = visit_next_list(m, (GenericList **)obj, errp); i; i = visit_next_list(m, &i, errp)) { + for (; (i = visit_next_list(m, prev, errp)) != NULL; prev = &i) { UserDefOneList *native_i = (UserDefOneList *)i; visit_type_UserDefOne(m, &native_i->value, NULL, errp); } -- cgit v1.1