From owner-svn-src-head@FreeBSD.ORG Sun Aug 8 22:06:34 2010 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 057041065678; Sun, 8 Aug 2010 22:06:34 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id BEC6E8FC1D; Sun, 8 Aug 2010 22:06:33 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 012571DD656; Mon, 9 Aug 2010 00:06:31 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id DE374172C1; Mon, 9 Aug 2010 00:06:31 +0200 (CEST) Date: Mon, 9 Aug 2010 00:06:31 +0200 From: Jilles Tjoelker To: "M. Warner Losh" Message-ID: <20100808220631.GA86477@stack.nl> References: <20100807.205058.260300877050427878.imp@bsdimp.com> <201008082037.o78KbLDt022321@haluter.fromme.com> <20100808.153608.1142818667055052395.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100808.153608.1142818667055052395.imp@bsdimp.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, olli@fromme.com Subject: Re: svn commit: r211023 - head/usr.sbin/syslogd X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 22:06:34 -0000 On Sun, Aug 08, 2010 at 03:36:08PM -0600, M. Warner Losh wrote: > In message: <201008082037.o78KbLDt022321@haluter.fromme.com> > Oliver Fromme writes: > : M. Warner Losh wrote: > : > In message: <201008071620.o77GKDBb091327@svn.freebsd.org> > : > Oliver Fromme 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