From owner-svn-src-all@FreeBSD.ORG Tue Aug 10 21:06:05 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B71701065687; Tue, 10 Aug 2010 21:06:05 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4B0D88FC13; Tue, 10 Aug 2010 21:06:04 +0000 (UTC) Received: from c122-106-147-41.carlnfd1.nsw.optusnet.com.au (c122-106-147-41.carlnfd1.nsw.optusnet.com.au [122.106.147.41]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o7AL5rx2024604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Aug 2010 07:05:53 +1000 Date: Wed, 11 Aug 2010 07:05:53 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: "M. Warner Losh" In-Reply-To: <20100810.120103.69891821625677670.imp@bsdimp.com> Message-ID: <20100811064553.G10707@delplex.bde.org> References: <201008101623.o7AGNs7I042679@haluter.fromme.com> <20100810.110642.335141733495090585.imp@bsdimp.com> <86sk2m1hsj.fsf@ds4.des.no> <20100810.120103.69891821625677670.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-108037158-1281474353=:10707" Cc: src-committers@freebsd.org, jilles@stack.nl, svn-src-all@freebsd.org, olli@fromme.com, olli@freebsd.org, svn-src-head@freebsd.org, des@des.no Subject: Re: svn commit: r211023 - head/usr.sbin/syslogd X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 21:06:05 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-108037158-1281474353=:10707 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 10 Aug 2010, M. Warner Losh wrote: > In message: <86sk2m1hsj.fsf@ds4.des.no> > Dag-Erling Sm=F8rgrav 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 analysi= s > : > * 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 { > =09unsigned char=09sa_len;=09=09/* total length */ > =09sa_family_t=09sa_family;=09/* address family */ > =09char=09=09sa_data[14];=09/* actually longer; address value */ > } __aligned(4); > > since that's what the ABI defines.... That's almost what I said to do a day or two ago. Not sure if 4 is correct= =2E The amd64 and i386 ABI's only requires 1. arm may (bogusly) require 4. The (POSIX) API requires struct sockaddr_storage to sufficient alignment for various things, including specifically casting of pointers to it into pointers to protocol-specific address structures, but it doesn't require this for struct sockaddr or stuct sockaddr_un. I checked a later version (2007 draft). Its requirement to cast struct sockaddr_un to struct sockaddr (NB: not the pointers) hasn't changed, and makes a little more sense to me now. I don't see how such a cast can succeed (unless the types are the same), but casting the pointers cannot work without any alignment requirements, while casting of whole objects can in some cases. Testing shows that casting a struct sockaddr_un to a struct sockaddr doesn't work at all, as expected: % gcc: % z.c: In function `foo': % z.c:10: error: conversion to non-scalar type requested %=20 % TenDRA (for C90 only) is much more verbose: % "z.c", line 10: Error: % [ISO C90 6.3.4]: Can't cast to the non-scalar type 'struct sockaddr'. % [ISO C90 6.3.4]: Illegal conversion from type 'struct sockaddr_un' to t= ype 'struct sockaddr'. % [ISO C90 6.3.4]: Can't perform this conversion using an explicit cast. This shows that structs cannot be cast even to the same type. Assignment of a struct sockaddr_un to a struct sockaddr would work if these types are the same, but that is not useful. POSIX's requirement is unimplementable. Bruce --0-108037158-1281474353=:10707--