Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #391250 > unrolled thread

__func__ is not a keyword

Back to article view | Back to comp.lang.c

Contents

  __func__ is not a keyword Thiago Adams <thiago.adams@gmail.com> - 2025-03-15 16:47 -0300
    Re: __func__ is not a keyword Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-15 14:20 -0700
      Re: __func__ is not a keyword Thiago Adams <thiago.adams@gmail.com> - 2025-03-15 18:30 -0300
        Re: __func__ is not a keyword Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-15 14:53 -0700
          Re: __func__ is not a keyword Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-15 15:04 -0700
      Re: __func__ is not a keyword Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-16 07:18 +0000
        Re: __func__ is not a keyword Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-16 02:06 -0700
          Re: __func__ is not a keyword Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-18 10:00 -0700
      Re: __func__ is not a keyword scott@slp53.sl.home (Scott Lurndal) - 2025-03-16 15:51 +0000
        Re: __func__ is not a keyword Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-16 11:51 -0700
          Re: __func__ is not a keyword Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-16 19:05 +0000
            Re: __func__ is not a keyword Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-16 13:29 -0700
              Re: __func__ is not a keyword Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-17 17:03 +0000
                Re: __func__ is not a keyword Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-17 13:09 -0700
                  Re: __func__ is not a keyword Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-17 20:31 +0000
            Re: __func__ is not a keyword James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-16 16:35 -0400
    Re: __func__ is not a keyword Mario Rosell <usenet@mariorosell.es> - 2026-04-17 20:19 +0000
      Re: __func__ is not a keyword Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-17 14:15 -0700

#391250 — __func__ is not a keyword

This program does not compile..in gcc and clang

int __func__  i =1;

int main () {}

error: expected identifier...

Standard has..

"The identifier __func__ shall be implicitly declared by the translator 
as if, immediately following
the opening brace of each function definition, the declaration" ...


My understand is that __func__   is not a keyword and that is something 
defined inside the functions.. so I don’t know why gcc and clang 
complains in the file scope.

[toc] | [next] | [standalone]

#391252

Thiago Adams <thiago.adams@gmail.com> writes:
> This program does not compile..in gcc and clang
>
> int __func__  i =1;
>
> int main () {}
>
> error: expected identifier...

The "i" makes that a syntax error anyway, even if "__func__" were
accepted as an ordinary identifier.  Still, you have found something
odd.

> Standard has..
>
> "The identifier __func__ shall be implicitly declared by the
> translator as if, immediately following
> the opening brace of each function definition, the declaration" ...
>
>
> My understand is that __func__   is not a keyword and that is
> something defined inside the functions.. so I don’t know why gcc and
> clang complains in the file scope.

If I change your program to:

    int __func__ = 1;
    int main(void) {}

both gcc and clang complain "error: expected identifier or ‘(’".
If I change it from __func__ to __foo__, neither gcc nor clang
complains.

    All identifiers that begin with a double underscore (__) or begin
    with an underscore (_) followed by an uppercase letter are reserved
    for any use, except those identifiers which are lexically identical
    to keywords.
    ...
    If the program declares or defines an identifier in a context in
    which it is reserved (other than as allowed by 7.1.4), the behavior
    is undefined.

So the program has undefined behavior, which means that terminating
the translation with the issuance of a diagnostic message is
permitted.

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

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#391254

Em 3/15/2025 6:20 PM, Keith Thompson escreveu:
> Thiago Adams <thiago.adams@gmail.com> writes:
>> This program does not compile..in gcc and clang
>>
>> int __func__  i =1;
>>
>> int main () {}
>>
>> error: expected identifier...
> 
> The "i" makes that a syntax error anyway, even if "__func__" were
> accepted as an ordinary identifier.  Still, you have found something
> odd.
> 

Yes sorry...

>> Standard has..
>>
>> "The identifier __func__ shall be implicitly declared by the
>> translator as if, immediately following
>> the opening brace of each function definition, the declaration" ...
>>
>>
>> My understand is that __func__   is not a keyword and that is
>> something defined inside the functions.. so I don’t know why gcc and
>> clang complains in the file scope.
> 
> If I change your program to:
> 
>      int __func__ = 1;
>      int main(void) {}
> 


yes..now I don't known if I did it right at first time.
but the problem I was talking about still there. :)

> both gcc and clang complain "error: expected identifier or ‘(’".
> If I change it from __func__ to __foo__, neither gcc nor clang
> complains.
> 
>      All identifiers that begin with a double underscore (__) or begin
>      with an underscore (_) followed by an uppercase letter are reserved
>      for any use, except those identifiers which are lexically identical
>      to keywords.
>      ...
>      If the program declares or defines an identifier in a context in
>      which it is reserved (other than as allowed by 7.1.4), the behavior
>      is undefined.
> 
> So the program has undefined behavior, which means that terminating
> the translation with the issuance of a diagnostic message is
> permitted.
> 
> 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
> 

I think __func__ is begin used as keyword inside gcc /clang.

Thanks for clarifying it.
I think this UB could be removed.

[toc] | [prev] | [next] | [standalone]

#391256

Thiago Adams <thiago.adams@gmail.com> writes:
> Em 3/15/2025 6:20 PM, Keith Thompson escreveu:
>> Thiago Adams <thiago.adams@gmail.com> writes:
>>> This program does not compile..in gcc and clang
>>>
>>> int __func__  i =1;
>>>
>>> int main () {}
>>>
>>> error: expected identifier...
>> The "i" makes that a syntax error anyway, even if "__func__" were
>> accepted as an ordinary identifier.  Still, you have found something
>> odd.
>> 
>
> Yes sorry...
>
>>> Standard has..
>>>
>>> "The identifier __func__ shall be implicitly declared by the
>>> translator as if, immediately following
>>> the opening brace of each function definition, the declaration" ...
>>>
>>>
>>> My understand is that __func__   is not a keyword and that is
>>> something defined inside the functions.. so I don’t know why gcc and
>>> clang complains in the file scope.
>> If I change your program to:
>>      int __func__ = 1;
>>      int main(void) {}
>> 
>
>
> yes..now I don't known if I did it right at first time.
> but the problem I was talking about still there. :)
>
>> both gcc and clang complain "error: expected identifier or ‘(’".
>> If I change it from __func__ to __foo__, neither gcc nor clang
>> complains.
>>      All identifiers that begin with a double underscore (__) or
>> begin
>>      with an underscore (_) followed by an uppercase letter are reserved
>>      for any use, except those identifiers which are lexically identical
>>      to keywords.
>>      ...
>>      If the program declares or defines an identifier in a context in
>>      which it is reserved (other than as allowed by 7.1.4), the behavior
>>      is undefined.
>> So the program has undefined behavior, which means that terminating
>> the translation with the issuance of a diagnostic message is
>> permitted.
>> 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
>
> I think __func__ is begin used as keyword inside gcc /clang.

That seems to be consistent with the behavior I see.

> Thanks for clarifying it.
> I think this UB could be removed.

If you mean that the program could be modified so it no longer has
undefined behavior, of course it could.  Just change __func__ to some
non-reserved identifier.

If you mean that the C standard could be changed so that declaring a
reserved identifier doesn't have undefined behavior, that would be
difficult, and I don't see the point.  Implementations are free to use
reserved identifiers for their own purposes.  That's why they're
reserved.

"Doctor, it hurts when I do this."

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#391258

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Thiago Adams <thiago.adams@gmail.com> writes:
[...]
>> I think __func__ is begin used as keyword inside gcc /clang.
>
> That seems to be consistent with the behavior I see.

And "__func__" appears in a data structure representing keywords in the
gcc sources (gcc/c-family/c-common.cc, c_common_reswords).

But again, unless it affects the defined behavior of some actual
program, it doesn't appear to be a conformance issue.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#391264

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

[toc] | [prev] | [next] | [standalone]

#391267

Kaz Kylheku <643-408-1753@kylheku.com> writes:
> 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."

But it produces a diagnostic

warning: ‘__func__’ is not defined outside of function scope

And in a very quick look through the documentation, I don't see
a way to disable that warning (other than "-w", which disables
all warnings).  Looks like they don't really want you using this
extension.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#391309

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>
>> 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."
>
> But it produces a diagnostic
>
> warning: ?__func__? is not defined outside of function scope
>
> And in a very quick look through the documentation, I don't see
> a way to disable that warning (other than "-w", which disables
> all warnings).  Looks like they don't really want you using this
> extension.

It seems more likely that they just don't care.  I expect there
has been very little demand for an option specifically to cover
this situation.

By the way, clang has -Wpredefined-identifier-outside-function,
along with the corresponding no- version to turn off the warning.

[toc] | [prev] | [next] | [standalone]

#391275

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Thiago Adams <thiago.adams@gmail.com> writes:
>> This program does not compile..in gcc and clang
>>
>> int __func__  i =1;
>>

>
>I'm mildly curious how gcc and clang treat "__func__" internally
>that leads to this odd behavior. 

From the gcc info page:

   GCC provides three magic variables that hold the name of the current
   function, as a string.  The first of these is '__func__', which is part
   of the C99 standard:

    The identifier '__func__' is implicitly declared by the translator as
   if, immediately following the opening brace of each function definition,
   the declaration

     static const char __func__[] = "function-name";

   appeared, where function-name is the name of the lexically-enclosing
   function.  This name is the unadorned name of the function.

[toc] | [prev] | [next] | [standalone]

#391278

scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>Thiago Adams <thiago.adams@gmail.com> writes:
>>> This program does not compile..in gcc and clang
>>>
>>> int __func__  i =1;
>>
>>I'm mildly curious how gcc and clang treat "__func__" internally
>>that leads to this odd behavior. 
>
> From the gcc info page:
>
>    GCC provides three magic variables that hold the name of the current
>    function, as a string.  The first of these is '__func__', which is part
>    of the C99 standard:
>
>     The identifier '__func__' is implicitly declared by the translator as
>    if, immediately following the opening brace of each function definition,
>    the declaration
>
>      static const char __func__[] = "function-name";
>
>    appeared, where function-name is the name of the lexically-enclosing
>    function.  This name is the unadorned name of the function.

But that doesn't tell us how it's treated internally and it's
inconsistent with gcc's actual behavior.  Both a look at gcc's
source code and its behavior indicate that gcc treats __func__ as
a keyword, which is inconsistent with the info page.  For example,
one would expect this:

int main(void) {
    {
        int __func__;
    }
}

to be accepted, with the inner definition of __func__ hiding the
implicit static declaration, but gcc reports a syntax error.

It's not a conformance issue, since __func__ is a reserved identifier
and any code that can tell whether it's a keyword has undefined
behavior.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#391279

On 2025-03-16, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> source code and its behavior indicate that gcc treats __func__ as
> a keyword, which is inconsistent with the info page.  For example,
> one would expect this:
>
> int main(void) {
>     {
>         int __func__;
>     }
> }
>
> to be accepted, with the inner definition of __func__ hiding the
> implicit static declaration, but gcc reports a syntax error.
>
> It's not a conformance issue, since __func__ is a reserved identifier
> and any code that can tell whether it's a keyword has undefined
> behavior.

But __func__ is not a reserved identifier! Inside a function, it's a
documented identifier with specified properties, and those properties do
not support an interpretation that it may be a keyword.

We have to distinguish between specific, defined, standard identifiers
allocated from a reserved namespace, and the reserved namespace itself.

If gcc (in c99 mode or later) *allowed*  int _Bool = 42;   would you
call that conforming, because _B* is in the reserved namespace, so
any behavior is okay?

Since __func__ is not described as existing outside of a function,
there, it is just an identifier landing in the reserved namespace.

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

[toc] | [prev] | [next] | [standalone]

#391281

Kaz Kylheku <643-408-1753@kylheku.com> writes:
> On 2025-03-16, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> source code and its behavior indicate that gcc treats __func__ as
>> a keyword, which is inconsistent with the info page.  For example,
>> one would expect this:
>>
>> int main(void) {
>>     {
>>         int __func__;
>>     }
>> }
>>
>> to be accepted, with the inner definition of __func__ hiding the
>> implicit static declaration, but gcc reports a syntax error.
>>
>> It's not a conformance issue, since __func__ is a reserved identifier
>> and any code that can tell whether it's a keyword has undefined
>> behavior.
>
> But __func__ is not a reserved identifier! Inside a function, it's a
> documented identifier with specified properties, and those properties do
> not support an interpretation that it may be a keyword.

"All identifiers that begin with a double underscore (__) or begin with
an underscore (_) followed by an uppercase letter are reserved for any
use, except those identifiers which are lexically identical to
keywords."

My interpretation is that the fact that the language defines a meaning
for __func__ doesn't exclude it from the set of reserved identifiers.

> We have to distinguish between specific, defined, standard identifiers
> allocated from a reserved namespace, and the reserved namespace itself.
>
> If gcc (in c99 mode or later) *allowed*  int _Bool = 42;   would you
> call that conforming, because _B* is in the reserved namespace, so
> any behavior is okay?

No, that's a syntax error because _Bool is a keyword, and keywords
are not identifiers.  "When preprocessing tokens are converted to
tokens during translation phase 7, if a preprocessing token could be
converted to either a keyword or an identifier, it is converted to
a keyword except in an attribute token."  Keywords and identifiers
are disjoint sets.

> Since __func__ is not described as existing outside of a function,
> there, it is just an identifier landing in the reserved namespace.

As far as the language is concerned yes, but gcc doesn't treat it
that way.

Are you suggesting that a conforming compiler must accept the above
code (defining __func__ in an inner scope)?  If so, I disagree.

gcc treating __func__ as a keyword arguably violates the intent of
the standard, but not in a way that affects conformance (unless I'm
missing something).  It behaves *as if* __func__ were an identifier
in the reserved space, with some instances of undefined behavior
behaving in odd but conforming ways.

(Practically, not being able to define my own entity named __func__
is no great loss.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#391288

On 2025-03-16, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Are you suggesting that a conforming compiler must accept the above
> code (defining __func__ in an inner scope)?  If so, I disagree.

I was initially divided on this one.

On the one hand, inside a function, __func__ is not reserved (for future
use); it is described as being bound as a variable name, and that makes
it compatible with lexical shadowing.

On the other hand, macros coming from standard headers could
have expansions that refer to __func__. (Macros not intended to be
used at file scope.)

If you redefine __func__, and use any macro or function that could be
implemented as a macro, then all bets are off.

The remaining doubt is this: could the implementation have code
generation features that rely on __func__, so that even if the
program doesn't use any macros or functions in that scope where
__func__ is redefined, there is a problem?

Say that the implementation supports a debug trace mode where for every
line executed it prints the function name and line number, and this
depends on generated code which expects __func__ to be undisturbed.
That seems like something in the space of "useful and good".

Of course, from a portable programming point of view, we must regard
__func__ as off-limits. In light of the above possibilities, though, it
seems that it would be best to formally interpret it that way, too.

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

[toc] | [prev] | [next] | [standalone]

#391291

Kaz Kylheku <643-408-1753@kylheku.com> writes:
> On 2025-03-16, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Are you suggesting that a conforming compiler must accept the above
>> code (defining __func__ in an inner scope)?  If so, I disagree.
>
> I was initially divided on this one.
>
> On the one hand, inside a function, __func__ is not reserved (for future
> use); it is described as being bound as a variable name, and that makes
> it compatible with lexical shadowing.

That's where I disagree, though I'm not 100% certain.

Identifiers starting with __ are not conditionally reserved, and
they're not reserved "for future use".  They're simply "reserved
for any use".

"If the program declares or defines an identifier in a context in
which it is reserved (other than as allowed by 7.1.4), the behavior
is undefined."

The fact that the language defines its own use for __func__ IMHO
doesn't unreserve it.  Referring to __func__ within a function
definition is of course allowed, but declaring or defining it still
has undefined behavior.

I'm using the N3096 draft at the moment; other drafts should have
similar or identical wording.  6.4.2.1 discusses identifiers,
and says that certain identifiers are "reserved for any use".
6.4.2.2 discusses predefined identifiers, specifically __func__
(which is the only predefined identifier).  I think you're assuming
that 6.4.2.2 describes an exception to the rules in 6.4.2.1.  I think
it doesn't; __func__ is specified in a way that's consistent with
it continuing to be reserved for any use.

And James Kuyper has pointed out the footnote in 6.4.2.2:

    Since the name __func__ is reserved for any use by the
    implementation (7.1.3), if any other identifier is explicitly
    declared using the name __func__, the behavior is undefined.

[...]

> Of course, from a portable programming point of view, we must regard
> __func__ as off-limits. In light of the above possibilities, though, it
> seems that it would be best to formally interpret it that way, too.

Agreed.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#391293

On 2025-03-17, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>> On 2025-03-16, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>> Are you suggesting that a conforming compiler must accept the above
>>> code (defining __func__ in an inner scope)?  If so, I disagree.
>>
>> I was initially divided on this one.
>>
>> On the one hand, inside a function, __func__ is not reserved (for future
>> use); it is described as being bound as a variable name, and that makes
>> it compatible with lexical shadowing.
>
> That's where I disagree, though I'm not 100% certain.
>
> Identifiers starting with __ are not conditionally reserved, and
> they're not reserved "for future use".  They're simply "reserved
> for any use".

I completely agree now.

Part of the cocept of an identifier being "reserved" is that the
implementation itself can refer to the identifier, blindly assuming that
the identifier is defined as documented, and has not been shadowed or
tampered with.

OK, that being said, since __func__ is described in a certain way,
namely *as-if* this declaration followed the opening brace
of the function::

  static const char __func__[] = "function-name";

I think that legitimizes the program using expressions like:

  sizeof __func__

with the expectation that this yields the number of characters
oin the function name, plus one.

That will obviously not work if the implementation takes some
license, and makes the implicit declaration as if it were:

  static const char *func = "function-name";

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

[toc] | [prev] | [next] | [standalone]

#391282

On 3/16/25 15:05, Kaz Kylheku wrote:
> On 2025-03-16, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
...
>> It's not a conformance issue, since __func__ is a reserved identifier
>> and any code that can tell whether it's a keyword has undefined
>> behavior.
> 
> But __func__ is not a reserved identifier!

Footnote 79 disagrees: "79) Since the name __func__ is reserved for any
use by the implementation (7.1.3), if any other identifier is explicitly
declared using the name __func__, the behavior is undefined."

Actually, I don't see how 7.1.3 applies. I think the conclusion is
correct, but the relevant citation should be 6.2.4.1p7: "All identifiers
that begin with a double underscore (__) ... are reserved for any use.
...". That wording used to be in 7.1.3. That wording was moved from
7.3.1 in n2573.pdf (2020-10-01) to 6.2.4.1 in n2596.pdf (2020-12-11).

[toc] | [prev] | [next] | [standalone]

#397644

__func__ is just an string that has name of the function it is in,
so for example:

	#include <stdio.h>
	int
	main(int argc, char** argv) {
		printf("we are on: %s\n", __func__);
		return 0;
	}

Will print:

	we are on: main

> My understand is that __func__   is not a keyword and that is something 
> defined inside the functions.. so I don’t know why gcc and clang 
> complains in the file scope.

Yes, it is a sort of atomic identified reserved by the compiler.
You can't redefine it, just like any normal identifier, if that
makes sense.    The compiler errors are from C not understanding
the code.

> "The identifier __func__ shall be implicitly declared by the translator 
> as if, immediately following
> the opening brace of each function definition, the declaration" ...

What it refers to is:

	type
	myfunction(...) { // <--- from here on, __func__ is available.
		...
	}

-- 
"I know thy works, that thou art neither cold nor hot: I would thou wert
cold or hot.  So then because thou art lukewarm, and neither cold nor
hot, I will spue thee out of my mouth." (Rev. 3:15-16)

[toc] | [prev] | [next] | [standalone]

#397648

You're replying to an article posted by Thiago Adams more than a
year ago.

You deleted the attribution line.  Please don't do that.

Mario Rosell <usenet@mariorosell.es> writes:
> __func__ is just an string that has name of the function it is in,
> so for example:
>
> 	#include <stdio.h>
> 	int
> 	main(int argc, char** argv) {
> 		printf("we are on: %s\n", __func__);
> 		return 0;
> 	}
>
> Will print:
>
> 	we are on: main

It's not *just* a string.  It's an implicitly defined static array of
char.

>> My understand is that __func__   is not a keyword and that is something 
>> defined inside the functions.. so I don’t know why gcc and clang 
>> complains in the file scope.
>
> Yes, it is a sort of atomic identified reserved by the compiler.
> You can't redefine it, just like any normal identifier, if that
> makes sense.    The compiler errors are from C not understanding
> the code.
>
>> "The identifier __func__ shall be implicitly declared by the translator 
>> as if, immediately following
>> the opening brace of each function definition, the declaration" ...
>
> What it refers to is:
>
> 	type
> 	myfunction(...) { // <--- from here on, __func__ is available.
> 		...
> 	}

This was all discussed at the time, and more accurately than in your
response.

The code in the original message was:

    int __func__  i =1;

which is a syntax error even if a non-reserved identifier is used.
It's likely that Thiago meant to write:

    int __func__ = 1;

But that has undefined behavior, because __func__ is a reserved
identifier due to the double underscore.

There are some oddities in the way gcc and clang treat __func__.
If you're curious, you can look up the thread from last year.
(gcc seems to treat __func__ as a keyword, which it isn't, but
that doesn't seem to cause any conformance issues, just some odd
wording in some diagnostics for bad code.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web