Hello, I have been experimenting with the remote protocol defined in the `src/remote/remote_protocol.x` (https://libvirt.org/git/?p=libvirt.git;a=blob_plain;f=src/remote/remote_p...), and noticed that there a number of types used that are not defined in the XDR RFC, specifically: unsigned char, char, unsigned short, short (I might have missed one or two). I'm wondering if these are missing typedefs, or whether they are custom extensions to the RFC. Does anyone have more information on this? If the latter case is the fact, are these values padded to 4 bytes per the spec?

On Wed, Jan 25, 2017 at 10:59 AM, Daniel P. Berrange <berrange(a)redhat.com&gt; wrote: > On Wed, Jan 25, 2017 at 10:55:37AM -0500, Matt Broadstone wrote: >> Hello, >> >> I have been experimenting with the remote protocol defined in the >> `src/remote/remote_protocol.x` >> (https://libvirt.org/git/?p=libvirt.git;a=blob_plain;f=src/remote/remote_p...), >> and noticed that there a number of types used that are not defined in >> the XDR RFC, specifically: unsigned char, char, unsigned short, short >> (I might have missed one or two). I'm wondering if these are missing >> typedefs, or whether they are custom extensions to the RFC. Does >> anyone have more information on this? If the latter case is the fact, >> are these values padded to 4 bytes per the spec? > > The libvirt RPC protocol is an internal impl detail, not for 3rd party > use. So our only goal is to be compatible with rpcgen binaries that are > used during builds on supported platforms. As such what's in the RFC > is not particularly relevant. > It does appear that these types are indeed supported by rpcgen (though in the cases where char's are used, your definitions would benefit from a conversion to `opaque`, as to not incur the padding overhead). Thank you for the clarification.