From owner-freebsd-current@FreeBSD.ORG Wed Mar 5 00:16:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 464A6E4C; Wed, 5 Mar 2014 00:16:19 +0000 (UTC) Received: from x0r.aitnet.org (x0r.aitnet.org [IPv6:2a00:1728:9:1::5]) by mx1.freebsd.org (Postfix) with ESMTP id BE6C2FF8; Wed, 5 Mar 2014 00:16:18 +0000 (UTC) Received: from terran.aitnet.org (unknown [77.70.75.103]) by x0r.aitnet.org (Postfix) with ESMTPSA id E28973F709; Wed, 5 Mar 2014 02:16:15 +0200 (EET) Date: Wed, 5 Mar 2014 02:16:15 +0200 From: Michael Pounov To: freebsd-current@freebsd.org, glebius@FreeBSD.org Subject: Re: Build failure on PowerPC in pf Message-Id: <20140305021615.9f12e7e3.misho@elwix.org> In-Reply-To: <20140304235700.GB64438@glebius.int.ru> References: <20140226212017.GY92037@funkthat.com> <20140304235700.GB64438@glebius.int.ru> Organization: ELWIX X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.6; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 00:16:19 -0000 We already have PR for this issue :) http://www.freebsd.org/cgi/query-pr.cgi?pr=187074 On Wed, 5 Mar 2014 03:57:00 +0400 Gleb Smirnoff wrote: > John-Mark, > > On Wed, Feb 26, 2014 at 01:20:17PM -0800, John-Mark Gurney wrote: > J> Justin Hibbits wrote this message on Wed, Feb 26, 2014 at 11:12 -0800: > J> > On Wed, Feb 26, 2014 at 10:32 AM, Justin Hibbits wrote: > J> > > Building on PowerPC I see the following failure: > J> > > > J> > > cc1: warnings being treated as errors > J> > > > J> > > /home/chmeee/freebsd/head/sys/modules/pf/../../netpfil/pf/pf_ioctl.c: > J> > > In function 'pfioctl': > J> > > /home/chmeee/freebsd/head/sys/modules/pf/../../netpfil/pf/pf_ioctl.c:1357:warning: > J> > > cast to pointer from integer of different size [-Wint-to-pointer-cast] > J> > > /home/chmeee/freebsd/head/sys/modules/pf/../../netpfil/pf/pf_ioctl.c:1359:warning: > J> > > cast to pointer from integer of different size [-Wint-to-pointer-cast] > J> > > /home/chmeee/freebsd/head/sys/modules/pf/../../netpfil/pf/pf_ioctl.c:1361:warning: > J> > > cast to pointer from integer of different size [-Wint-to-pointer-cast] > J> > > > J> > > struct pf_rule has counter_u64_t entries, which are actually pointers > J> > > to uint64_t's. These pointers get assigned from the result of > J> > > counter_u64_fetch(), which returns a uint64_t. Looks to me like > J> > > there's a bug in here, but I have no idea what to do to fix it. And > J> > > I'm surprised this hasn't been reported against other 32-bit > J> > > architectures. > J> > > J> > Replying to myself, it looks like this was broken by r261882. > J> > J> This comment says it all: > J> 1352 glebius 261882 /* > J> 1353 * XXXGL: this is what happens when internal kernel > J> 1354 * structures are used as ioctl API structures. > J> 1355 */ > J> > J> So, one way could be to use a union for the states: > J> union { > J> struct { > J> counter_u64_t states_cur; > J> counter_u64_t states_tot; > J> counter_u64_t src_nodes; > J> } k; > J> struct { > J> uint64_t states_cur; > J> uint64_t states_tot; > J> uint64_t src_nodes; > J> } u; > J> } u; > J> > J> The other option is to cast through uintptr_t... > J> > J> Even though it'd make the code a bit more ugly, I'd vote for the union, > J> since it's designed for what the code is trying to do... > > Would above guarantee us that members of "k" won't cross on members > of "u" when we fill them one by one? > > u.states_cur = counter_u64_fetch(k.states_cur); > u.states_tot = counter_u64_fetch(k.states_tot); > > I'd prefer: > > union states_cur { > counter_u64_t k; > uint64_t u; > } > union states_tot { > counter_u64_t k; > uint64_t u; > } > union src_nodes { > counter_u64_t k; > uint64_t u; > } > > Or am I overcautious? > > -- > Totus tuus, Glebius. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Best Regards! Michael Pounov +359 888 737358, +359 899 737358 WWW: http://www.elwix.org/ XMPP: misho@aitnet.org Skype: mpunov