>>> 	I believe u_int32_t is much more correct here.  there's no particular
>>> 	relationship between in_addr_t and IPv6 address.
>>> 	please backout the change.
>>the problem is that u_int32_t isn't portable (i.e, not every platform
>>has it), and it's only used in one place in the code (in one section of
>>your ipv6 mods). is there a more portable method of what you were
>>trying to do?
>
>	hmm, in that case, I can think of two ways:
>	- if u_int32_t is not available, use configure.in to #define u_int32_t
>	  into 32bit unsigned integer type.
>	- don't try to pack 4 bytes together.  do it in per-byte manner.
>	the latter one looks much easier, and much more safe.

	the latter one.

itojun


Index: ftp.c
===================================================================
RCS file: /cvsroot/basesrc/usr.bin/ftp/ftp.c,v
retrieving revision 1.99
diff -u -r1.99 ftp.c
--- ftp.c	2000/06/11 02:12:05	1.99
+++ ftp.c	2000/06/11 13:03:00
@@ -1596,12 +1596,11 @@
 				data_addr.su_family = AF_INET6;
 				data_addr.su_len = sizeof(struct sockaddr_in6);
 			    {
-				in_addr_t *p32;
-				p32 = (in_addr_t *)&data_addr.su_sin6.sin6_addr;
-				p32[0] = htonl(pack4(addr, 0));
-				p32[1] = htonl(pack4(addr, 4));
-				p32[2] = htonl(pack4(addr, 8));
-				p32[3] = htonl(pack4(addr, 12));
+				int i;
+				for (i = 0; i < sizeof(struct in6_addr); i++) {
+					data_addr.su_sin6.sin6_addr.s6_addr[i] =
+					    addr[i] & 0xff;
+				}
 			    }
 				data_addr.su_port = htons(pack2(port, 0));
 				break;