This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]