Re: __func__ is not a keyword

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