M. Warner Losh wrote:
> /*
> * Macros to cast a struct sockaddr, or parts thereof. struct
> * sockaddr's alginment is loose to later be cast to a sockaddr_in or
> * sockaddr_in6. On architectures with strict alignment requirements,
> * this leads to compiler warnings because the compiler doesn't know
> * the ABI guarantees proper alignment.
> */
>
> But this leads me to think that the right fix might be:
>
> /*
> * Structure used by kernel to store most
> * addresses.
> */
> struct sockaddr {
> unsigned char sa_len; /* total length */
> sa_family_t sa_family; /* address family */
> char sa_data[14]; /* actually longer; address value */
> } __aligned(4);
>
> since that's what the ABI defines....
Yes, that would solve most of the problems, at least the ones
related to struct sockaddr.
Can we make that change to struct sockaddr, or does it cause
unwanted side-effects?
I could do a full "make universe" to test it, but it would
probably take two days on my 9-current machine.
> : > : @@ -2410,8 +2419,8 @@
> : > : }
> : > : reject = 0;
> : > : for (j = 0; j < 16; j += 4) {
> : > : - if ((*(u_int32_t
> *)&sin6->sin6_addr.s6_addr[j] & *(u_int32_t *)&m6p->sin6_addr.s6_addr[j])
> : > : - != *(u_int32_t
> *)&a6p->sin6_addr.s6_addr[j]) {
> : > : + if
> ((UINT32_CAST(sin6->sin6_addr.s6_addr[j]) &
> UINT32_CAST(m6p->sin6_addr.s6_addr[j]))
> : > : + !=
> UINT32_CAST(a6p->sin6_addr.s6_addr[j])) {
> : > : ++reject;
> : > : break;
> : > : }
> : > :
> : > :
> : >
> : > Why 16 and 4 here? What's so magical about them?
> :
> : 4 = bytes in a uint32_t, 16 = bytes in an ipv6 address.
>
> Isn't that better served by 'sizeof(uint32_t)' and
> 'sizeof(ipv6_addr_t)'?
Yes, probably.
Best regards
Oliver
--
``We are all but compressed light'' (Albert Einstein)
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
