From owner-freebsd-net@FreeBSD.ORG Fri Jun 7 06:08:39 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mandree.no-ip.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id E35FD3F0; Fri, 7 Jun 2013 06:08:38 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id AE15023CEB6; Fri, 7 Jun 2013 08:08:37 +0200 (CEST) Message-ID: <51B178E5.6010500@FreeBSD.org> Date: Fri, 07 Jun 2013 08:08:37 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Maxim Dounin Subject: Re: IN6_IS_ADDR_* macros use invalid type punning? References: <51B0EFC2.1020406@FreeBSD.org> <20130606232925.GU72282@mdounin.ru> In-Reply-To: <20130606232925.GU72282@mdounin.ru> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 06:08:39 -0000 Am 07.06.2013 01:29, schrieb Maxim Dounin: > [...] > >> try.c:9:5: warning: dereferencing type-punned pointer will break >> strict-aliasing rules [-Wstrict-aliasing] >> int r = IN6_IS_ADDR_V4MAPPED((&sin6.sin6_addr)); >> ^ >> try.c:9:5: warning: dereferencing type-punned pointer will break >> strict-aliasing rules [-Wstrict-aliasing] > > [...] > Gleb already committed a fix for this 16 months ago > (unfortunately, correct patch description was lost in transit): > > http://svnweb.freebsd.org/base?view=revision&revision=230584 Great. Thank you for the pointer. I could have checked head/ first indeed. Looking at : The code committed at that time is lucky that htonl() and ntohl() are implemented the same way; all changed macros should be changed to use == htonl(1) or == htonl(0x0000ffff), just to get the proper meaning across. ntohl would have to be applied to the __u6_addr instead, but is less efficient because it is not open to compile-time evaluation, unlike htonl(CONSTANT_ADDRESS). And indeed the commit log is a bit less compelling than might have fostered the propagation. It looks like it were only about qualifiers, but it is also about violating aliasing rules per ISO 9899. > Probably it's a good idea to MFC the fix. Please let's get this MFC'd and MFS'd (while it won't make releng/8.4 at least we can have stable/8 fixed, too) and get the system-headers induced warning done away with on all supported branches. Best Matthias