From patchwork Thu May 28 23:18:44 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steve Ellcey X-Patchwork-Id: 6975 Received: (qmail 89929 invoked by alias); 28 May 2015 23:18:51 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 89918 invoked by uid 89); 28 May 2015 23:18:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mailapp01.imgtec.com Message-ID: <1432855124.20199.35.camel@ubuntu-sellcey> Subject: Re: [PATCH] Fix strict-aliasing warning in resolv/res_hconf.c From: Steve Ellcey Reply-To: To: Roland McGrath CC: Florian Weimer , Pedro Alves , Andreas Schwab , Paul Eggert , Date: Thu, 28 May 2015 16:18:44 -0700 In-Reply-To: <20150528225742.A6C552C3B00@topped-with-meat.com> References: <5bfa6373-3817-4d31-a5ee-a8676e79b723@BAMAIL02.ba.imgtec.org> <555BB55E.3050304@cs.ucla.edu> <1432075989.16668.62.camel@ubuntu-sellcey> <555BC19B.90001@cs.ucla.edu> <1432077972.16668.65.camel@ubuntu-sellcey> <20150519235817.9516F2C3A73@topped-with-meat.com> <555C3E0B.2040404@redhat.com> <555C48F0.2030208@redhat.com> <1432139240.16668.77.camel@ubuntu-sellcey> <55658C2A.70209@redhat.com> <5565B4D3.3090401@redhat.com> <1432828842.20199.15.camel@ubuntu-sellcey> <20150528201038.003B42C3B00@topped-with-meat.com> <1432850960.20199.25.camel@ubuntu-sellcey> <20150528225742.A6C552C3B00@topped-with-meat.com> MIME-Version: 1.0 On Thu, 2015-05-28 at 15:57 -0700, Roland McGrath wrote: > > I could, but I would rather not since I normally only build glibc for > > MIPS and it always takes me a while to figure out the options and > > settings for an x86 build. I did a build using GCC 4.9.2 for MIPS and > > did not see any significant code differences with this patch (i.e. I did > > not see an extra data copy on MIPS). > > OK, that's good enough for me to assume that there won't be any extra data > copy on any machine with a reasonable compiler. (I actually asked about > x86_64 specifically because I wouldn't care about the MIPS code being > suboptimal as long as the x86 code was not.) > > The only other thing I'd say about the patch is that the temporary > variable should be declared in the innermost possible scope. > > > Thanks, > Roland OK, moving the declaration is easy enough to do, I will put it in the for loop where it is used. Steve Ellcey sellcey@imgtec.com 2015-05-28 Steve Ellcey * resolv/res_hconf.c (_res_hconf_reorder_addrs): Use a union to copy data from cur_ifr->ifr_addr. diff --git a/resolv/res_hconf.c b/resolv/res_hconf.c index 73942e8..b9c229d 100644 --- a/resolv/res_hconf.c +++ b/resolv/res_hconf.c @@ -439,18 +439,24 @@ _res_hconf_reorder_addrs (struct hostent *hp) for (cur_ifr = ifr, i = 0; i < num; cur_ifr = __if_nextreq (cur_ifr), ++i) { + union + { + struct sockaddr sa; + struct sockaddr_in sin; + } ss; + if (cur_ifr->ifr_addr.sa_family != AF_INET) continue; ifaddrs[new_num_ifs].addrtype = AF_INET; - ifaddrs[new_num_ifs].u.ipv4.addr = - ((struct sockaddr_in *) &cur_ifr->ifr_addr)->sin_addr.s_addr; + ss.sa = cur_ifr->ifr_addr; + ifaddrs[new_num_ifs].u.ipv4.addr = ss.sin.sin_addr.s_addr; if (__ioctl (sd, SIOCGIFNETMASK, cur_ifr) < 0) continue; - ifaddrs[new_num_ifs].u.ipv4.mask = - ((struct sockaddr_in *) &cur_ifr->ifr_netmask)->sin_addr.s_addr; + ss.sa = cur_ifr->ifr_netmask; + ifaddrs[new_num_ifs].u.ipv4.mask = ss.sin.sin_addr.s_addr; /* Now we're committed to this entry. */ ++new_num_ifs;