On Sep 25, 2014, at 6:11 PM, David Vandevoorde <[email protected]> wrote: > On Sep 25, 2014, at 7:38 PM, Richard Smith <[email protected]> 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.
_______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
