On 01/20/2016 08:19 AM, Markus Armbruster wrote:
> Eric Blake writes:
>
>> All other successful clients of visit_start_struct() were paired
>> with an unconditional visit_end_struct(); but the generated
>> code for events was relying on qmp_output_visitor_cleanup() to
>> work on an incomplete vis
On 01/20/2016 10:10 AM, Eric Blake wrote:
> Oops. It all gets cleaned up in 33 when visit_end_struct() loses the
> errp argument, but in the meantime, I think the most robust way to write
> this would be:
>
> out_obj:
> visit_end_struct(v, err ? NULL : &err);
> if (err) {
> ...
>
>>
>> I
Eric Blake writes:
> On 01/20/2016 08:19 AM, Markus Armbruster wrote:
>> Eric Blake writes:
>>
>>> All other successful clients of visit_start_struct() were paired
>>> with an unconditional visit_end_struct(); but the generated
>>> code for events was relying on qmp_output_visitor_cleanup() to
On 01/20/2016 08:19 AM, Markus Armbruster wrote:
> Eric Blake writes:
>
>> All other successful clients of visit_start_struct() were paired
>> with an unconditional visit_end_struct(); but the generated
>> code for events was relying on qmp_output_visitor_cleanup() to
>> work on an incomplete vis
Eric Blake writes:
> All other successful clients of visit_start_struct() were paired
> with an unconditional visit_end_struct(); but the generated
> code for events was relying on qmp_output_visitor_cleanup() to
> work on an incomplete visit.
Disgusting, isn't it? :)
>
All other successful clients of visit_start_struct() were paired
with an unconditional visit_end_struct(); but the generated
code for events was relying on qmp_output_visitor_cleanup() to
work on an incomplete visit. Alter the code to guarantee that
the struct is completed, which will make a futur
