On Sun, Aug 08, 2010 at 03:36:08PM -0600, M. Warner Losh wrote:
> In message: <201008082037.o78kbldt022...@haluter.fromme.com>
> Oliver Fromme <o...@fromme.com> writes:
> : M. Warner Losh wrote:
> : > In message: <201008071620.o77gkdbb091...@svn.freebsd.org>
> : > Oliver Fromme <o...@freebsd.org> writes:
> : > : Author: olli
> : > : Date: Sat Aug 7 16:20:12 2010
> : > : New Revision: 211023
> : > : URL: http://svn.freebsd.org/changeset/base/211023
> : > : Modified: head/usr.sbin/syslogd/Makefile
> : > :
> ==============================================================================
> : > : --- head/usr.sbin/syslogd/Makefile Sat Aug 7 16:14:40 2010
> (r211022)
> : > : +++ head/usr.sbin/syslogd/Makefile Sat Aug 7 16:20:12 2010
> (r211023)
> : > : @@ -12,7 +12,7 @@ SRCS= syslogd.c ttymsg.c
> : > : DPADD= ${LIBUTIL}
> : > : LDADD= -lutil
> : > : -WARNS?= 3
> : > : +WARNS?= 6
> : > : .if ${MK_INET6_SUPPORT} != "no"
> : > : CFLAGS+= -DINET6
> : > This breaks MIPS, so I've reverted it. Please make sure that all
> : > architectures work when bumping up WARNS.
> : Thanks for fixing it for me.
> : I did make the universe check, but apparently I did something
> : wrong, so I didn't notice the problem. I'm sorry for that.
> The casting that syslogd does with struct sockaddrFOO is what triggers
> it. I'm not sure how to fix it, so there's about 6 or 8 programs in
> the tree that have WARNS lowered to 3 because of it.
This problem is common with programs that use getaddrinfo() and then
look into the address family specific parts of the address (it was
probably not the intention of the getaddrinfo() API to do this very
often). Obviously, when ai_family is the corresponding value, the
ai_addr really points to that particular kind of sockaddr, but gcc only
knows that struct sockaddr_in and struct sockaddr_in6 have a higher
alignment requirement than struct sockaddr.
In some cases, the address may already be copied, and making the
destination the family-based type or struct sockaddr_storage (which has
a high alignment requirement) will avoid problems.
In other cases, I propose adding a cast to void * in between, like
(struct sockaddr_in *)(void *)ai->ai_addr
Note that this workaround must not be applied mindlessly to avoid
-Wcast-align, but only when it is known from other information that the
object really has that type.
If you don't like this workaround, perhaps copy the data to a variable
of the correct type. Addresses are not particularly big so the
performance hit should not be bad.
It is unfortunate to have to miss other warnings because of this.
--
Jilles Tjoelker
_______________________________________________
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"
