From owner-svn-src-head@FreeBSD.ORG Tue Aug 10 20:41:23 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 19C5F106564A; Tue, 10 Aug 2010 20:41:23 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id CB37F8FC12; Tue, 10 Aug 2010 20:41:22 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 960AB1FFC33; Tue, 10 Aug 2010 20:41:21 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 560568455C; Tue, 10 Aug 2010 22:41:21 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "M. Warner Losh" References: <201008101623.o7AGNs7I042679@haluter.fromme.com> <20100810.110642.335141733495090585.imp@bsdimp.com> <86sk2m1hsj.fsf@ds4.des.no> <20100810.120103.69891821625677670.imp@bsdimp.com> Date: Tue, 10 Aug 2010 22:41:20 +0200 In-Reply-To: <20100810.120103.69891821625677670.imp@bsdimp.com> (M. Warner Losh's message of "Tue, 10 Aug 2010 12:01:03 -0600 (MDT)") Message-ID: <8639ump5e7.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 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: Tue, 10 Aug 2010 20:41:23 -0000 "M. Warner Losh" writes: > Dag-Erling Sm=C3=B8rgrav writes: > > "M. Warner Losh" 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. > */ That sounds more like what I had in mind (my point being that the compiler is *right* to not make any such assumptions unless we say it's safe to do so) > 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, unfortunately that's not portable. I like the way it's done in sockaddr_storage, but we can't do that here except possibly using anonymous unions, which aren't portable either. > > > Why 16 and 4 here? What's so magical about them? > > 4 =3D bytes in a uint32_t, 16 =3D bytes in an ipv6 address. > Isn't that better served by 'sizeof(uint32_t)' and > 'sizeof(ipv6_addr_t)'? Probably... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no