<html>
<head>
<title>N2340 C99 Compatibility : __func__ and predeclared identifiers (revision 1)</title>
</head>

<body>
Document Number: N2340<br/>
2007-07-19<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 (revision 2)</h1>

<h2>1. Intent</h2>

The 1999 revision of the C standard introduced the concept of 'a
predeclared identifier'.
<p>
This feature is used to capture function names as string literals and to
assist diagnostic libraries.  This small change seems preferable to
changing the preprocessor to provide equivalent functionality, educating
it to parse function definitions 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.
<p>
The format of the literal has been deliberately left implementation-defined
so that compilers can provide the facility that is most useful to their
user community.
<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 a different level of
detail for information about the signature of a function if they
preferred.  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 well 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, <strike>else</strike> <b>otherwise</b>
 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>, a <em>function-local predefined
variable</em> denotes a local object of static storage duration that
is implicitly defined (see 3.3.2 basic.scope.local for its scope).

<p>
The function-local predefined variable
<code>__func__</code> is defined as if a definition of the form


<blockquote>
<code>static const char __func__[] = "<em>function-name</em>";</code>
</blockquote>
had been provided, where <code><em>function-name</em></code> is an
implementation-defined string.
It is unspecified whether such a variable has an address distinct from
that of any other object in the program.
[ <em>Footnote:</em> Implementations are permitted to provide
additional predefined variables with names that are reserved
to the implementation (17.4.3.1.2 global.names).
If a predefined variable is not used (3.2 basic.def.odr), its string value need not be
present in the program image. ]

<p>
[ <em>Example:</em>
<pre>
struct S {
  S() : s(__func__) { }            // ok
  const char *s;
};
void f(const char * s = __func__); // error: __func__ is undeclared
</pre>
]

</blockquote>
