[cxx-abi-dev] On __func__

[John McCall]

On Sep 25, 2014, at 6:11 PM, David Vandevoorde <daveed at edg.com> wrote:
> On Sep 25, 2014, at 7:38 PM, Richard Smith <richardsmith at google.com> wrote:
>> Hi!
>> 
>> Per C++ [dcl.fct.def.general]p8, __func__ acts as if it were defined as a static local variable defined within the surrounding function. This has two impacts on the ABI which we don't seem to capture today, and for which implementations vary. Consider:
>> inline const char *f() { return __func__; }
>> To my reading, the standard requires f() to return the same pointer in every translation unit. But... what is the mangled name of that string literal, and what does it contain? (We must produce the same contents in every TU in order to give it the same type.)
>> 
>> Implementations vary only slightly on the first question. GCC mangles it as _ZZ1fvE8__func__ but makes the symbol internal. EDG and Clang make it internal with no particular symbol. None of these approaches is conforming. We could perhaps call this a standard defect: perhaps the address of the object named by __func__ should be permitted to differ on each evaluation.
>> 
>> Implementations vary much more significantly on the second question, giving different values (and thus different types) for __func__ in the same inline function. Is there anything we can do to make this work? I don't see any good options here, but I wanted to check with this group before suggesting the standard be changed (for instance, by making __func__ a prvalue of type 'const char*' rather than an lvalue of type 'const char[N]').
>> 
>> Thoughts?
> 
> I like you example standard change.

Yeah, __func__ strikes me a lot like string literals: promising address equality has significant hidden costs for no user benefit.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20140925/12bbccab/attachment.html>