Eric Blake <ebl...@redhat.com> writes:

> On 11/07/2017 04:12 AM, Markus Armbruster wrote:
>> Juan Quintela <quint...@redhat.com> writes:
>> 
>>> Alistair Francis <alistair.fran...@xilinx.com> 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?

Reply via email to