All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Michal Nazarewicz <mina86@mina86.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kernel.h: Remove ancient __FUNCTION__ hack
Date: Wed, 04 Feb 2015 14:49:17 -0800	[thread overview]
Message-ID: <1423090157.30454.1.camel@perches.com> (raw)
In-Reply-To: <20150204143515.8bd14a53fceae8f38b0b0e8d@linux-foundation.org>

On Wed, 2015-02-04 at 14:35 -0800, Andrew Morton wrote:
> On Wed, 04 Feb 2015 14:05:15 -0800 Joe Perches <joe@perches.com> wrote:
> > On Wed, 2015-02-04 at 23:01 +0100, Rasmus Villemoes wrote:
> > > On Wed, Feb 04 2015, Joe Perches <joe@perches.com> wrote:
> > > > On Wed, 2015-02-04 at 21:55 +0100, Rasmus Villemoes wrote:
> > > >> On Wed, Feb 04 2015, Joe Perches <joe@perches.com> wrote:
> > > >> > On Wed, 2015-02-04 at 10:48 +0100, Rasmus Villemoes wrote:
> > > >> >> __FUNCTION__ hasn't been treated as a string literal since gcc 3.4, so
> > > >> >> this only helps people who only test-compile using 3.3
> > > >> >> (compiler-gcc3.h barks at anything older than that). Besides, there
> > > >> >> are almost no occurrences of __FUNCTION__ left in the tree.
> > > >> > The remaining  uses of __FUNCTION__ need converting first.
> > > >> Why? __FUNCTION__ is recognized just fine by gcc as an alias for __func__.
> > > > And icc and clang and ...?
> > > clang yes, icc probably (from quick googling). 
> > Cool, but it does seem safer/more conservative to me to
> > convert the last 3 uses before doing this.

[]

>  arch/x86/kernel/hpet.c                       |    2 +-
>  arch/x86/kernel/rtc.c                        |    4 ++--
>  arch/x86/platform/intel-mid/intel_mid_vrtc.c |    2 +-
>  drivers/acpi/acpica/utdebug.c                |    4 ++--
>  drivers/block/xen-blkfront.c                 |    2 +-
>  include/acpi/acoutput.h                      |    6 +++---
>  6 files changed, 10 insertions(+), 10 deletions(-)

Thanks.  I had submitted patches for all the
actual code uses (but not the comments) awhile ago.

trivia about macros vs c99 predefined identifiers below:

> diff -puN include/acpi/acoutput.h~kernelh-remove-ancient-__function__-hack-fix include/acpi/acoutput.h
[]
> @@ -240,7 +240,7 @@
>  /*
>   * If ACPI_GET_FUNCTION_NAME was not defined in the compiler-dependent header,
>   * define it now. This is the case where there the compiler does not support
> - * a __FUNCTION__ macro or equivalent.
> + * a __func__ macro or equivalent.

Do these still make sense?  __func__ isn't a macro.

> @@ -249,12 +249,12 @@
[]
> - * and macros such as __FUNCTION__.
> + * and macros such as __func__.
[]
> -/* Compiler supports __FUNCTION__ (or equivalent) -- Ignore this macro */
> +/* Compiler supports __func__ (or equivalent) -- Ignore this macro */
[]
> diff -puN drivers/acpi/acpica/utdebug.c~kernelh-remove-ancient-__function__-hack-fix drivers/acpi/acpica/utdebug.c

> @@ -111,8 +111,8 @@ void acpi_ut_track_stack_ptr(void)
[]
> - *              This allows compiler macros such as __FUNCTION__ to be used
> - *              with no change to the debug output.
> + *              This allows compiler macros such as __func__ to be used with no
> + *              change to the debug output.



  reply	other threads:[~2015-02-04 22:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-04  9:48 [PATCH] kernel.h: Remove ancient __FUNCTION__ hack Rasmus Villemoes
2015-02-04 19:06 ` Joe Perches
2015-02-04 20:55   ` Rasmus Villemoes
2015-02-04 21:03     ` Joe Perches
2015-02-04 22:01       ` Rasmus Villemoes
2015-02-04 22:05         ` Joe Perches
2015-02-04 22:35           ` Andrew Morton
2015-02-04 22:49             ` Joe Perches [this message]
2015-02-04 23:05               ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1423090157.30454.1.camel@perches.com \
    --to=joe@perches.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=mina86@mina86.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.