qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [Qemu-devel] [PATCH v3 01/46] Replace all occurances of _


From: Markus Armbruster
Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH v3 01/46] Replace all occurances of __FUNCTION__ with __func__
Date: Tue, 07 Nov 2017 11:12:14 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Juan Quintela <address@hidden> writes:

> Alistair Francis <address@hidden> wrote:
>> Replace all occurs of __FUNCTION__ except for the check in checkpatch
>> with the non GCC specific __func__.
>>
>> One line in hcd-musb.c was manually tweaked to pass checkpatch.
>>
>> Signed-off-by: Alistair Francis <address@hidden>
>> Cc: Gerd Hoffmann <address@hidden>
>> Cc: Andrzej Zaborowski <address@hidden>
>> Cc: Stefano Stabellini <address@hidden>
>> Cc: Anthony Perard <address@hidden>
>> Cc: John Snow <address@hidden>
>> Cc: Aurelien Jarno <address@hidden>
>> Cc: Yongbok Kim <address@hidden>
>> Cc: Peter Crosthwaite <address@hidden>
>> Cc: Stefan Hajnoczi <address@hidden>
>> Cc: Fam Zheng <address@hidden>
>> Cc: Juan Quintela <address@hidden>
>> Cc: "Dr. David Alan Gilbert" <address@hidden>
>> Cc: address@hidden
>> Cc: address@hidden
>> Cc: address@hidden
>> Reviewed-by: Eric Blake <address@hidden>
>> Reviewed-by: Stefan Hajnoczi <address@hidden>
>
> Reviewed-by: Juan Quintela <address@hidden>
>
>
>> diff --git a/audio/audio_int.h b/audio/audio_int.h
>> index 5bcb1c60e1..543b1bd8d5 100644
>> --- a/audio/audio_int.h
>> +++ 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__.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]