This is the mail archive of the
mailing list for the GCC project.
Re: RFC: Lazy __FUNCTION__ etc
- To: Zack Weinberg <zackw at stanford dot edu>
- Subject: Re: RFC: Lazy __FUNCTION__ etc
- From: Nathan Sidwell <nathan at codesourcery dot com>
- Date: Wed, 21 Mar 2001 10:02:16 +0000
- CC: gcc-patches at gcc dot gnu dot org
- Organization: Codesourcery LLC
- References: <20010320200540.B3208@stanford.edu>
Zack Weinberg wrote:
> This patch causes us to allocate the strings for __FUNCTION__,
> __PRETTY_FUNCTION__, and __func__ lazily. At present they are
> We still get the semantics of __func__ wrong, but they are no more
> wrong than they were before. I believe I know how to correct __func__
> within the new framework, and will attempt that after this patch goes in.
As you've observed for C++ we treat __func__ and __FUNCTION__ the same, and
in a C99 manner of
static const char __func__ = "foo";
I had thought C was doing the same, ho hum.
I think it would be a mistake for __FUNCTION__ and __func__ to have
(subtly) different semantics. Now that C99 has spoken, we should
treat them as array variables, not string constants.
> The patch is not quite ready for inclusion, because it somehow breaks
> C++'s ext/pretty3.C and ext/pretty4.C tests. I believe pretty4 is in
> error: it wants __FUNCTION__ to be a different object from a string
> constant with the same contents, and a different object for two
> (overloaded) functions with the same base name. This has never been
> true in the C compiler, but apparently used to be true for C++. I
This naturally follows from the c99 definition of __func__.
> implicit specialization). Formerly, __PRETTY_FUNCTION__ was not
> evaluated for template functions until they were specialized, so both
> of them came out like "f1(T) [with T = float]". Now
> __PRETTY_FUNCTION__ is evaluated immediately, so the generic is just
> called "f1(T)". This is undesired. I do not know why it happened or
> how to put the semantics back the way they were - I do see some code
> aimed at evaluating _P_F_ at template specialization time, in pt.c,
> but I have no idea how we get there...
IIR, this was some pretty horrible subterfuge Mark (sorry) put in when I
fixed P_F etc to have the correct type inside template functions.
How about having __func__ __FUNCTION__ and _P_F_ as special grammar
rules which create the appropriate VAR_DECL, if it's not already
in existence? wouldn't that give the fewest changes elsewhere?
Dr Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
'But that's a lie.' - 'Yes it is. What's your point?'
email@example.com : http://www.cs.bris.ac.uk/~nathan/ : firstname.lastname@example.org