Date: Tue, 10 Aug 2010 12:01:03 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: des@des.no Cc: src-committers@FreeBSD.org, jilles@stack.nl, svn-src-all@FreeBSD.org, olli@fromme.com, olli@FreeBSD.org, svn-src-head@FreeBSD.org Subject: Re: svn commit: r211023 - head/usr.sbin/syslogd Message-ID: <20100810.120103.69891821625677670.imp@bsdimp.com> In-Reply-To: <86sk2m1hsj.fsf@ds4.des.no> References: <201008101623.o7AGNs7I042679@haluter.fromme.com> <20100810.110642.335141733495090585.imp@bsdimp.com> <86sk2m1hsj.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <86sk2m1hsj.fsf@ds4.des.no>
Dag-Erling Smørgrav <des@des.no> writes:
: "M. Warner Losh" <imp@bsdimp.com> writes:
: > /*
: > * Macros to cast a struct sockaddr, or parts thereof.
: > * On architectures with strict alignment requirements, the compiler
: > * can bogusly warn about alignment problems since its static analysis
: > * is insufficient for it to know that with the APIs used, there
: > * really is no alignment issue.
: > */
:
: That's a bit harsh on the compiler, don't you think? It never pays to
: hurt the compiler's feelings :)
/*
* 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....
: > : @@ -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)'?
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100810.120103.69891821625677670.imp>