[Libguestfs] [PATCH libnbd 1/2] generator: Handle closure args (cbargs) specially.

[Eric Blake]

On 8/9/19 7:59 AM, Richard W.M. Jones wrote:
> If we accept that callbacks will never handle the full range of
> parameters then we can simplify the generator quite a bit by using a
> special type for closure args vs normal method args.

Nice.

> 
> This removes many asserts and quite a bit of unreachable code
> (eg. Python code for handling ArrayAndLen in normal methods that was
> never used).

Or having a closure arg within a callback.

> 
> The output of the generator after this commit should be identical.
> 
> It's possible to go a little further if we wanted: CBArrayAndLen is
> only ever used for ‘uint32_t’ arrays.  CBMutable is only ever used for
> ‘int*’.  We could make CB* types which only handle those cases.
> ---
>  generator/generator | 428 +++++++++++++++++++-------------------------
>  1 file changed, 186 insertions(+), 242 deletions(-)
> 

Relatively large, but does look like a simplification.


> +and cbarg =
> +| CBArrayAndLen of arg * string (* array + number of entries *)
> +| CBBytesIn of string * string (* like BytesIn *)
> +| CBInt of string          (* like Int *)
> +| CBInt64 of string        (* like Int64 *)
> +| CBMutable of arg         (* mutable argument, eg. int* *)

Should we use 'of cbarg' instead of 'of arg' for CBArrayAndLen and
CBMutable?  Or, as you said above, we could make it a specific type
instead of trying to keep a generic wrapper, with the cost that if we
add new callbacks down the road we may want to reintroduce the generic
wrapper at that time instead of continuing to add one type per use.

Looks good to me.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20190809/21952b03/attachment.sig>