[2689] in Kerberos_V5_Development
Re: More Unicos porting hell (struct inaddr)
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Wed Oct 29 13:58:25 1997
Date: Wed, 29 Oct 1997 13:57:25 -0500
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Assar Westerlund <assar@sics.se>
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, Ken Hornstein
<kenh@cmf.nrl.navy.mil>,
krbdev@MIT.EDU
In-Reply-To: Assar Westerlund's message of 29 Oct 1997 12:14:16 +0100,
<5l4t607ref.fsf@assaris.pdc.kth.se>
From: Assar Westerlund <assar@sics.se>
Date: 29 Oct 1997 12:14:16 +0100
> It basically appears to be inviting you to make the (unsafe)
> assumption that st_addr fits into a long. Most modern code uses the
> memcpy because future IP addresses (like IPv6) won't be 32 bits
> long. The Cray code, on the other hand, is practically forcing you
> to assume you can move IP addresses around using long's....
Sorry? IPv6 is not using `struct in_addr', it's using `struct
in6_addr'.
Sure, there's a separate structure for IPv6 addresses, just as there's a
separate structure for Chaosnet (for those people who remember ChaosNet
from the MIT AI lab) addresses.
That doesn't mean, though, that you shouldn't use the memcpy. In fact,
the most generic way to write the code uses the generic form of the
structure (i.e., struct sockaddr vs. struct sockaddr_in). My complaint
was the Cray was rewarding folks who use the more non-portable form, and
punishing folks that use the more portable form.
Sigh.
- Ted
