On Tue, Feb 8, 2011 at 11:09 AM, Hartmut Reuter <[email protected]> wrote: > Simon Wilkinson wrote: >> >> On 8 Feb 2011, at 15:20, Derrick Brashear wrote: >> >>> struct { >>> int addrtype; >>> int addrlen; >>> int addr<> >>> } rx_addr; >>> >>> #define RX_ADDRTYPE_IPV4 1 >>> #define RX_ADDRTYPE_IPV6 2 >> >> Why not just use an opaque? That way you don't get into any of the >> ordering issues that ints bring with them. >> >> struct { >> int addrtype; >> opaque addr<>; >> } rx_addr; > > opaque requires xdr_alloc and later xdr_free of the data and in the case of > IPv4 the address typically is used as an integer which then would have been > first converted from the opaque (including changing host byte order). > > Therefore I had proposed in my change I8aa46a29: > src/fsint/fs_rxosd_common.xg > for both address types to use afs_uint32s: > > union ipadd switch(afs_int32 vsn) { > case 4: > afs_uint32 ipv4; > case 6: > afs_uint32 ipv6[4]; > }; > > I also think instead of inventing new constants it's better to use the > version numbers 4 and 6 directly. > > In the case of IPv6 the application easily can fill the contents into the > host's struct in6_addr using the u6_addr32 fields while for IPv4 the address > can be used directly.
the only problem is we're back to a union with fixed discrimination that doesn't allow us to add things later. > If we create such a new struct one could think of also adding the port > number and the service number as additional fields. for things that don't want those, it's extra memory, though. -- Derrick _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
