This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ PATCH]: __FUNCTION__ handling
Mark Mitchell wrote:
> Does this make us emit __FUNCTION__ just because the user says
> something like:
>
> const char *c = __FUNCTION__
>
> ? That should still not require that the actual __FUNCTION__ itself
> be emitted; that should only happen if __FUNCTIO__ is addressed.
why?
void foo ()
{
static const char wibble[] = "wibble";
const char *wptr = wibble;
const char *fptr = __FUNCTION__;
assert (fptr == __FUNCTION__);
assert (wptr == wibble);
}
`wibble' and `__FUNCTION__' should behave the same here. Both asserts
should be ok.
Yes -- but that can be accomplished simply by making fptr point to the
same copy of the literal -- as if the user had written:
assert ("foo" == "foo")
(I know that in C/C++ that's not got well-defined behavior; but, if
the compiler shares the literal, then the assert will work out.)
I've never been too pleased with how we handle these things. I like
your patch because of its consistency with user-declared arrays; the
less magic the better. On the other hand, the point of __FUNCTION__
is that it is a kind-of magic thing in between a macro and a variable;
when you write:
void f (const char *):
void g () { f (__FUNCTION__); }
the idea is that this is as efficient as:
void g() { f ("g"); }
I think that historically __FUNCTION__ was supposed to be relatively
closely equivalent to __FILE__ and __LINE__, except that you can't do
it in the preprocessor.
However, now we should try to adhere to the C9X draft wording quoted
by the GCC manual:
The identifier `__func__' is implicitly declared by the translator
as if, immediately following the opening brace of each function
definition, the declaration
static const char __func__[] = "function-name";
appeared...
Your patch does that, for sure. The question is if it can be done
more efficiently, without emitting __FUNCTION__ itself. I think it
could be, if we could arrange to use the same string literal eerywhere
within the function (but *not* across functions; the C9X definition
implies that you can tell the difference between two functions with
the same name because their __func__ arrays should be at different
addresses.) I'm ambivalent.
What's the test-case that doesn't work without this part of your
change?
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com