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.
If we create such a new struct one could think of also adding the port number
and the service number as additional fields.
Cheers,
Hartmut
Cheers,
Simon.
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
--
-----------------------------------------------------------------
Hartmut Reuter e-mail [email protected]
phone +49-89-3299-1328
fax +49-89-3299-1301
RZG (Rechenzentrum Garching) web http://www.rzg.mpg.de/~hwr
Computing Center of the Max-Planck-Gesellschaft (MPG) and the
Institut fuer Plasmaphysik (IPP)
-----------------------------------------------------------------
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
