Received: from eggs.gnu.org ([2001:4830:134:3::10]:35768) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCLAg-0002FG-Ku for qemu-devel@nongnu.org; Wed, 08 Nov 2017 02:53:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eCLAf-0000MH-C0 for qemu-devel@nongnu.org; Wed, 08 Nov 2017 02:53:14 -0500 From: Markus Armbruster References: <87efpmccvu.fsf@secure.laptop> <87bmke4cu9.fsf@dusky.pond.sub.org> <51d103e9-8d6b-8c83-dd69-effe997d4813@redhat.com> Date: Wed, 08 Nov 2017 08:52:51 +0100 In-Reply-To: <51d103e9-8d6b-8c83-dd69-effe997d4813@redhat.com> (Eric Blake's message of "Tue, 7 Nov 2017 13:41:49 -0600") Message-ID: <87shdptdf0.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v3 01/46] Replace all occurances of __FUNCTION__ with __func__ List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Juan Quintela , Stefano Stabellini , Fam Zheng , qemu-block@nongnu.org, Peter Crosthwaite , "Dr. David Alan Gilbert" , qemu-devel@nongnu.org, Yongbok Kim , qemu-arm@nongnu.org, Gerd Hoffmann , Stefan Hajnoczi , xen-devel@lists.xenproject.org, Anthony Perard , alistair23@gmail.com, Alistair Francis , John Snow , Aurelien Jarno Eric Blake writes: > On 11/07/2017 04:12 AM, Markus Armbruster wrote: >> Juan Quintela writes: >> >>> Alistair Francis wrote: >>>> Replace all occurs of __FUNCTION__ except for the check in checkpatch >>>> with the non GCC specific __func__. >>>> > >>>> +++ b/audio/audio_int.h >>>> @@ -253,7 +253,7 @@ static inline int audio_ring_dist (int dst, int src, int len) >>>> #define AUDIO_STRINGIFY(n) AUDIO_STRINGIFY_(n) >>>> >>>> #if defined _MSC_VER || defined __GNUC__ >>>> -#define AUDIO_FUNC __FUNCTION__ >>>> +#define AUDIO_FUNC __func__ >>>> #else >>>> #define AUDIO_FUNC __FILE__ ":" AUDIO_STRINGIFY (__LINE__) >>>> #endif >>> >>> Unrelated to this patch .... >>> Do we really support other compilers than msc and gcc? >> >> Let me rephrase the question: do we really support compilers that don't >> understand __func__? The presence of numerous unconditional uses of >> __func__ in the tree means the answer is no. Let's replace AUDIO_FUNC >> by plain __func__. > > Answered elsewhere in patch 3/46 (where we DO replace AUDIO_FUNC by > __func__). I see. Put 03/46 first, so we don't have to mess with AUDIO_FUNC twice?