Re: [Xen-devel] [PATCH v2 16/22] golang/xenlight: implement keyed union C to Go marshaling

[Nick Rosbrook <rosbrookn@xxxxxxxxx>]

> > It looks like this is duplicating (differently!) the field-copying code
> > from golang_define_from_C.  Is there any reason you couldn't have a
> > single function, `xenlight_golang_fields_from_C`, which would be used
> > for both?

No, I should be able to re-factor that. Thanks.

> Actually, it turns out we don't strictly need to duplicate this at all,
> if we use the `typeof` operator, like this:
>
> ---
> typedef typeof(((struct libxl_channelinfo *)NULL)->u.pty)
> libxl_channelinfo_connection_union_pty;
>
> typedef typeof(((struct libxl_domain_build_info *)NULL)->u.hvm)
> libxl_domain_build_info_type_union_hvm;
>
> typedef typeof(((struct libxl_domain_build_info *)NULL)->u.pv)
> libxl_domain_build_info_type_union_pv;
>
> typedef typeof(((struct libxl_domain_build_info *)NULL)->u.pvh)
> libxl_domain_build_info_type_union_pvh;
>
> typedef typeof(((struct libxl_device_usbdev *)NULL)->u.hostdev)
> libxl_device_usbdev_type_union_hostdev;
>
> typedef typeof(((struct libxl_device_channel *)NULL)->u.socket)
> libxl_device_channel_connection_union_socket;
> ---
>
> This guarantees we'll have the correct layout for the resulting type.

Well that's pretty cool.

> I talked to Ian Jackson, and he agreed that long-term it would be good
> for the C generator to generate named types for these union elements
> (likke you have here).  If you felt really motivated you could do that
> now; but I think using the `typeof` trick would be suitable to get this
> patch in.

I'll take a look at least and see if I can get it done fairly easily.
Otherwise, I'll use this trick.

Thanks,
-NR

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel