On 8/13/19 5:06 AM, Richard W.M. Jones wrote:
This was not permitted by the API before, but would in some circumstances work. --- generator/generator | 10 ++++++++++ 1 file changed, 10 insertions(+)
Requires nbd_pread_structured and nbd_block_status to pass in a callback (good). Requires nbd_set_debug_callback to provide a non-NULL pointer (a bit rough, as now you can't pass NULL to deinstall your handler and get back to the default behavior - but how often are applications likely to deinstall a debug handler? If it becomes a problem, we can improve the 'closure' type to take a bool argument stating whether the closure accepts NULL, defaulting to false, but set to true for debug_closure - or we could rewrite nbd_set_debug_callback to take an OClosure instead of a Closure). Requires completion_callback to be non-NULL, but we relax that restriction by moving to OClosure. ACK. Yes, the first four can be applied no matter what else we discuss.
diff --git a/generator/generator b/generator/generator index 7f97163..01da1c3 100755 --- a/generator/generator +++ b/generator/generator @@ -3664,6 +3664,16 @@ let generate_lib_api_c () = in List.iter ( function + | Closure { cbname } -> + let value = match errcode with + | Some value -> value + | None -> assert false in
The generator has a check that: (* !may_set_error is incompatible with String parameters because * we have to do a NULL-check on those which may return an error. *) Should this check be widened to cover Closure, so that we get a nicer error than 'assert false' if someone goofs in adding a new signature that uses Closure with the wrong return type? Can be a separate patch, since we missed doing it for Enum and Flags in earlier patches, which also are instances where we used 'assert false' and require the ability to return an error. Doesn't affect runtime correctness, just ease-of-use when re-compiling changes to the generator. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org