<html>
<head>
<title>n2202 C99 Compatibility : __func__ and predeclared identifiers</title>
</head>

<body>
Document Number: n2202(07-0062)<br/>
2007-03-09<br/>
Alisdair Meredith &lt;alisdair.meredith@uk.renaultf1.com><br/>
Jens Maurer &lt;Jens.Maurer@gmx.net><br/>

<h1>C99 Compatibility : __func__ and predeclared identifiers</h1>

<h2>1. Intent</h2>

The 1999 revision of the C standard introduced the concept of 'a
predeclared identifier'.
<p>
This feature is used capture function names as string literals, to
assist diagnostic libraries.  This small change seems preferable to
changing the preprocessor to provide equivalent functionality, educating
it to parse function definitions in along the way.
<p>
Although it would seem expensive to introduce a string literal for every
function, it should be relatively simple to optimise the literal away in
the majority of cases where the function never refers to it. Likewise the
proposal mandates that the literal is simply the unqualified name of the
function, so overload sets could all share the same representation of the
literal.
<p>
In writing up the proposal the format of the literal has been deliberately
specified, as an implementation defined string is less helpful in when 
trying to write a portable diagnostic library facility.  The unadorned
function name seems the least controversial representation. It is the lowest
common denominator and has the benefit of being the same format as would be
emitted by a C99 compiler. Awkward cases such as constuctors, destructors
and conversion operators are addressed explicitly.
<p>
It would be quite possible for vendors to offer additional predefined
identifiers using similarly reserved names (eg using double underscores)
This would allow vendors to supply more information about the signature if
they preferred, namespace or class idenfiers etc.  While such extensions
would be conforming, they are not a required by for this proposal.
<p>
The final point of note is that the library text for the C99 assert macro
was updated to require the value of __func__, as will as __FILE__ and __LINE__.
As C++ includes the C90 standard and C99 standard library by reference no
further changes are necessary.



<h2>2.  Proposed wording</h2>

The wording proposed hereinafter relies on the proposed resolution for core issue 452.
<p>

Add a new paragraph after 3.3.1 basic.scope.pdecl paragraph 7:
<blockquote>
<b>The point of declaration for a function-local predefined variable
(8.4 dcl.fct.def) is immediately before the <em>function-body</em> of
a function definition.</b>
</blockquote>

Change 3.3.2 basic.scope.local paragraph 2 as indicated:
<blockquote>
The potential scope of a function parameter name <b>or of a
function-local predefined variable</b> in a function definition
(8.4 dcl.fct.def) begins at its point of declaration.  If the function
has a <em>function-try-block</em> the potential scope of a parameter
<b>or function-local predefined variable</b> ends at the end of the
last associated handler, else it ends at the end of the outermost
block of the function definition. ...
</blockquote>


At the end of 8.4 dcl.fct.def, add new paragraphs:
<blockquote>
In the <em>function-body</em>, the <em>function-local predefined variable</em>
<code>__func__</code> denotes a local object of static storage
duration as if a definition of the form
<blockquote>
<code>static const char __func__[] = "<em>simple-function-name</em>";</code>
</blockquote>
had been provided, where <code><em>simple-function-name</em></code> is
the <em>simple name</em> of the function as specified below. [
<em>Footnote:</em> Implementations are encouraged to provide
additional predefined variables with names that are reserved
to the implementation (17.4.3.1.2 global.names), for example a
function-local predefined variable that reflects a
function's signature (1.3.11 defns.signature).  If a predefined variable
is not used, its string value should not be present in the program
image. ]  [ Note: The name <code>__func__</code> is in scope
throughout the <em>function-body</em> (3.3.2 basic.scope.local),
because a user-declared entity cannot have the same name (17.4.3.1.2
global.names). ]

<ul>
<li>The simple name of a function is the simple name
of its <em>declarator-id</em>.
<li>The simple name of a <em>declarator-id</em> is the simple name of
its <em>unqualified-id</em>.
<li>The simple name of an <em>identifier</em> is that
<em>identifier</em>.
<li>The simple name of an <em>operator-function-id</em> is that
<em>operator-function-id</em> with intervening white-space removed.
<li>The simple name of a <em>simple-template-id</em> is the
simple name of its <em>template-name</em>.
<li>The simple name of an <em>unqualified-id</em> that is of
the form <code>~ <em>class-name</em></code> is the simple name of that
<em>class-name</em>, prefixed by "~". [ <em>Note:</em> The
<em>class-name</em>, in turn, is an <em>identifier</em> or a
<em>simple-template-id</em>. ]
<li>The simple name of a <em>template-id</em> is the simple
name of its <em>simple-template-id</em> or of its
<em>operator-function-id</em>.
<li>The simple name of a <em>conversion-function-id</em> is
the string literal "conversion operator"

</ul>
<p>
The <code><em>simple-function-name</em></code> is encoded as if the
definition had been written in the source character set and then
translated into the execution character set as specified by
translation phase 5 (2.1 lex.phases).
<p>
[ <em>Example:</em>
<pre>
namespace N { void f(); }
void N::f() { }                 // __func__ is "f"

struct S {
  S() : s(__func__) { }         // ok, s points to "S"
  ~S() { }                      // __func__ is "~S"
  operator int() { }            // __func__ is "conversion operator"
  template&lt;class T> int g();
  const char *s;
};
S operator +(S,S) { }           // __func__ is "operator+"
template&lt;> int S::g&lt;int>() { }  // __func__ is "g"
</pre>
]

</blockquote>
