Derrick Brashear wrote:
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.

But only in the memory, not on the wire.


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.

Could be another case (not 4 or 6)



--
-----------------------------------------------------------------
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

Reply via email to