public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: linux-kernel@vger.kernel.org
Subject: Re: __FUNCTION__
Date: Tue, 8 Jan 2002 23:23:13 -0800	[thread overview]
Message-ID: <20020109072313.GA18359@kroah.com> (raw)
In-Reply-To: <3C3B664B.3060103@intel.com> <20020108220149.GA15816@kroah.com> <20020108235649.A26154@xs4all.nl> <20020108231147.GA16313@kroah.com> <20020108181202.A986@twiddle.net>
In-Reply-To: <20020108181202.A986@twiddle.net>

On Tue, Jan 08, 2002 at 06:12:02PM -0800, Richard Henderson wrote:
> 
> __FUNCTION__ was never a string literal in g++ because you can't decide
> what the name of a template is until you instantiate it.

According to the info page it was:
	   The compiler automagically replaces the identifiers with a
	   string literal containing the appropriate name. 

This is written right after a lovely C++ example of using __FUNCTION__
and __PRETTY_FUNCTION__.  But I can understand the difficulties of
determining this for some C++ cases.

> Having __FUNCTION__ be a magic cpp thingy means there is a translation
> phase violation.  Preprocessor macros are expanded in phase 4, string
> concatenation happens in phase 6, syntactic and symantic analysis
> doesn't happen until phase 7.
> 
> So changing this allows us to change two things: (1) the integrated
> preprocessor can concatenate adjacent string literals and do lexical
> analysis exactly as described in the standard, and (2) removes an
> irrelevant difference between c and c++ so that at some point we can
> support both with a single front-end.

So, if you are going to change this (well, sounds like it is already
done), what is the timeline from taking a well documented feature and
breaking it (based on the example in the info page)?  First a warning,
and then an error, right?  What version of the compiler emits a warning,
and what future version will emit an error?  I didn't see anything about
these kinds of changes in the gcc development plan, or am I missing some
documentation somewhere?

thanks,

greg k-h

  reply	other threads:[~2002-01-09  7:25 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-08 21:36 __FUNCTION__ Vladimir Kondratiev
2002-01-08 21:59 ` __FUNCTION__ Ian S. Nelson
2002-01-08 22:17   ` __FUNCTION__ Greg KH
2002-01-08 23:09   ` __FUNCTION__ Vladimir Kondratiev
2002-01-08 22:01 ` __FUNCTION__ Greg KH
2002-01-08 22:56   ` __FUNCTION__ jtv
2002-01-08 23:11     ` __FUNCTION__ Greg KH
2002-01-08 23:39       ` __FUNCTION__ David Weinehall
2002-01-08 23:51         ` __FUNCTION__ Andrew Morton
2002-01-09  0:04           ` __FUNCTION__ David Weinehall
2002-01-09  0:14             ` __FUNCTION__ Andrew Morton
2002-01-09  0:23           ` __FUNCTION__ Anton Altaparmakov
2002-01-08 23:42       ` __FUNCTION__ jtv
2002-01-09  2:12       ` __FUNCTION__ Richard Henderson
2002-01-09  7:23         ` Greg KH [this message]
2002-01-09  7:32           ` __FUNCTION__ Neil Booth
2002-01-09 22:35           ` __FUNCTION__ Richard Henderson
2002-01-09  9:05       ` __FUNCTION__ Martin Dalecki

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=20020109072313.GA18359@kroah.com \
    --to=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox