Deutsch   English   Français   Italiano  
<874izuhsfr.fsf@nosuchdomain.example.com>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: __func__ is not a keyword
Date: Sat, 15 Mar 2025 14:53:12 -0700
Organization: None to speak of
Lines: 79
Message-ID: <874izuhsfr.fsf@nosuchdomain.example.com>
References: <vr4lgu$63fu$1@dont-email.me>
	<87bju2htxy.fsf@nosuchdomain.example.com>
	<vr4rh9$b38v$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 15 Mar 2025 22:53:13 +0100 (CET)
Injection-Info: dont-email.me; posting-host="65766d3f94e315a3ff32ef79be62617b";
	logging-data="315024"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/Cgm44BoBe3WJzC6MtasU1"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:MOPWJUUyZPyjp/8H6y3TDieHb3k=
	sha1:dbDNVog1P30NpvrAF8KQp0p+W0U=
Bytes: 4016

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 */