From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29021 invoked by alias); 9 Jan 2012 05:35:22 -0000 Received: (qmail 28781 invoked by uid 22791); 9 Jan 2012 05:35:20 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp14.ono.com (HELO resmaa14.ono.com) (62.42.230.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 09 Jan 2012 05:35:08 +0000 Received: from gaara.hadrons.org (85.136.45.65) by resmaa14.ono.com (8.5.113) (authenticated as guillemj@ono.com) id 4EFDA806001EBC89; Mon, 9 Jan 2012 06:35:01 +0100 Received: from guillem by gaara.hadrons.org with local (Exim 4.77) (envelope-from ) id 1Rk7sp-0006Bz-G5; Mon, 09 Jan 2012 06:34:59 +0100 Date: Mon, 09 Jan 2012 05:35:00 -0000 From: Guillem Jover To: "Joseph S. Myers" Cc: Mike Frysinger , libc-ports@sourceware.org Subject: Re: [PATCH ports] Use __unused0 instead of __unused for user visible struct members Message-ID: <20120109053459.GA23789@gaara.hadrons.org> References: <20120102031859.GA11067@gaara.hadrons.org> <201201020106.15682.vapier@gentoo.org> <20120104071225.GA29510@gaara.hadrons.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org X-SW-Source: 2012-01/txt/msg00028.txt.bz2 On Wed, 2012-01-04 at 11:57:22 +0000, Joseph S. Myers wrote: > On Wed, 4 Jan 2012, Guillem Jover wrote: > > The patch seems to have arrived now on the libc-alpha list. In any > > case I don't see the harm in applying this one to the ports tree? > > In general, textual differences (including whitespace) between libc and > ports versions of a file should be limited to those that genuinely result > from differences between the architectures, kernel ports, etc.; a cleanup > is applied to ports versions only after it is applied to the libc > versions. Fair enough. thanks, guillem