From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42588) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWktZ-0000C0-CJ for qemu-devel@nongnu.org; Wed, 24 Sep 2014 07:38:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWktU-0002yz-E9 for qemu-devel@nongnu.org; Wed, 24 Sep 2014 07:38:05 -0400 Date: Wed, 24 Sep 2014 13:37:51 +0200 From: Tobias Klauser Message-ID: <20140924113751.GA3408@distanz.ch> References: <1411061124-21108-1-git-send-email-tklauser@distanz.ch> <542279B5.7070502@msgid.tls.msk.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <542279B5.7070502@msgid.tls.msk.ru> Subject: Re: [Qemu-devel] [Qemu-trivial] [PATCH] disas/arm: Remove redefinition of ATTRIBUTE_UNUSED List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Tokarev Cc: qemu-trivial@nongnu.org, qemu-devel@nongnu.org On 2014-09-24 at 09:58:45 +0200, Michael Tokarev wrote: > 18.09.2014 21:25, Tobias Klauser wrote: > > ATTRIBUTE_UNUSED is already defined in disas/bfd.h, which is included. > > Thus, there is no need to redefine it. > > Is there any harm in keeping it here? No. > While it really is a redifinition, I'm not sure what's the right thing > here. This whole code is not from qemu, it is an external source imported, > and that source is being maintained (but under different license as has > already been discussed, so keeping changes at minimum might not be that > good idea anymore). On the other hand this symbol is so common it should > be defined in a common header. Yet on another hand, for these external > sources wich has public API, it might not be a good idea to define it in > a header to start with, because it might clash with project-local define, > so it might be better to define it in either private header or in individual > source. Ah, I didn't know it was non-qemu code (but now that I look at it again, I probably should have realized that sooner ;). Thanks for the explanation. > Oh well, so much for so trivial thing... ;) :) Sorry, it wasn't my intention to cause much discussion, trouble or work for maintainers with that patch. I don't feel strongly about, I just stumbled across it when browsing the source and found it odd to see a macro defined just below the #include of a header which defines the same macro. Please just ignore the patch then :) Thanks Tobias