Re: __func__ is not a keyword

On 2025-03-15, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

I'm mildly curious how gcc and clang treat "__func__" internally
that leads to this odd behavior.  The obvious way to implement it
would be to internally create a declaration of __func__ on entry
to each function definition, which shouldn't cause the symptom
you're seeing.  But it's not a conformance issue

The main reason is this:

  "As an extension, at file (or, in C++, namespace scope), __func__
   evaluates to the empty string."

You might think that this is due to history: GCC had function
name access as the __FUNCTION__ and __PRETTY__FUNCTION__ extensions
before __func__ was standardized. __func__ is still documented
as an alternate name for __FUNCTION__.

However, it is not the case that __FUNCTION__ was always documented
as expanding at file scope!

The documentation for GCC 2.95 does not mention any such thing. It
specifies that __FUNCTION__ is a variable, and that it gives the name of
the current function, not specifying anything about when there is no
current functiona:

  These names are not macros: they are predefined string variables. For
  example, `#ifdef __FUNCTION__' does not have any special meaning
  inside a function, since the preprocessor does not do anything special
  with the identifier __FUNCTION__.

It turns out that the documentation for 2.95 lied. The GCC 3.6.4
documentation (GCC 3 end-of-life release) contradicts the above,
revealing that only in C++ had those identifiers been variables:

  These identifiers are not preprocessor macros. In GCC 3.3 and earlier,
  in C only, __FUNCTION__ and __PRETTY_FUNCTION__ were treated as string
  literals; they could be used to initialize char arrays, and they could
  be concatenated with other string literals. GCC 3.4 and later treat
  them as variables, like __func__. In C++, __FUNCTION__ and
  __PRETTY_FUNCTION__ have always been variables.

However, the 3.4.6 documentation still does not say anything
about file scope, even though it does describe the C99 __func__
already. I don't have a build of 3.4.6 to test the actual behavior.

So it doesn't look as if recognition of __func__ at file scope
is simply due to it being an alias for an existing GCC feature
which had that behavior historically. It looks like an extension
they bestowed upon __func__, and in so doing also upon the
__FUNCTION__.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca