On 09/28/2012 10:14 AM, Laine Stump wrote: > On 09/21/2012 05:16 PM, Kyle Mestery wrote: >> Add the ability for the Qemu V3 migration protocol to >> include transporting network configuration. A generic >> framework is proposed with this patch to allow for the >> transfer of opaque data. > > Functionally this all looks good (and sounds like it lives up to that in > practice :-). There are some code style issues, though... > > 2) Internally, we usually store the enum value rather than the string, > and translate to/from string form during XML parse/format. (For some > reason, normal usage is to specify it in the struct as an int, with a > comment giving the actual type: > > > int vporttype; /* enum virNetDevVPortProfile */ > > > I'm not sure why that is, to be truthful - Eric or Dan?) For public API - ABI stability. The C standard does not give any guarantees about the sizeof an enum member in a struct, and at least gcc allows compiler flags that change struct layout based on whether enums are packed to the smallest integer size that holds all the values of the enum or is as wide as an int. Since we don't control the compiler flags used by a client app that includes our public headers, we're better off avoiding the issue. Using 'int' instead of the enum type frees us from the ABI questions. For private API - consistent coding style. Besides, C is not as typesafe as C++ with regards to enums, so it's not like we're losing much functionality. -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list