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: Mon, 17 Mar 2025 17:03:19 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 35
Message-ID: <20250317095147.230@kylheku.com>
References: <vr4lgu$63fu$1@dont-email.me>
 <87bju2htxy.fsf@nosuchdomain.example.com>
 <6sCBP.1140938$t84d.713135@fx11.iad>
 <87bju0x10g.fsf@nosuchdomain.example.com> <20250316115725.530@kylheku.com>
 <8734fcwwhf.fsf@nosuchdomain.example.com>
Injection-Date: Mon, 17 Mar 2025 18:03:20 +0100 (CET)
Injection-Info: dont-email.me; posting-host="9eb98ac983869514f441a96c41207106";
	logging-data="573384"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19x1gU/DodJNwLMGFsI9QAFE82Dhkb5FrA="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:dMRMaf1/J1u5rlN/lRzZwc0Vw08=
Bytes: 2635

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