Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.lang.c
Subject: Re: __func__ is not a keyword
Date: Sun, 16 Mar 2025 07:18:38 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 55
Message-ID: <20250315234302.412@kylheku.com>
References: <vr4lgu$63fu$1@dont-email.me>
 <87bju2htxy.fsf@nosuchdomain.example.com>
Injection-Date: Sun, 16 Mar 2025 08:18:39 +0100 (CET)
Injection-Info: dont-email.me; posting-host="9304094fac7608a7c5a324c0f9e098b2";
	logging-data="1409127"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/4enIa/6fMM22H3beBWH7ZOdpc7hy0kc0="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:JUR9KNmOFVQuw48KN8l/8fS62V0=
Bytes: 3467

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