Re: [PATCH] [Coding Style]: fs/ext{3,4}/ext{3,4}_jbd{,2}.c

[Al Viro <viro@ZenIV.linux.org.uk>]

On Fri, Jan 04, 2008 at 09:12:28PM -0700, Andreas Dilger wrote:

> What's wrong with __FUNCTION__?  I thought that was ANSI C?

__FUNCTION__ is a gccism of dubious taste - it pretends to be a macro
when it's something far out of scope of preprocessor.  Think for a minute
and you'll see why - you can't expand it until you are done with parsing.

__func__ is C99, but it's not what __FUNCTION__ used to be - it's not a
string literal.  6.4.2.2(1):

	The identifier __func__ shall be 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.

IOW, it's a phase 7 (parsing and translation of translation units) and not
phase 4 (preprocessor).  Practical implications are:
	* _way_ fewer kludges
	* it happens after phase 6 (string literal concatenation)
So __FUNCION__ " is called" within body of foo() would result in
"foo is called" while __func__ "is called" is a syntax error.

These days old gcc __FUNCTION__ is gone; it's a macro expanding to __func__,
so behaviour does *not* match the original (see above).

The thing is, it's not something like __FILE__ or __LINE__ and never had been;
it tried to pretend that it had been like those but that required far too
nasty kludges and these days it is firmly in the "nothing to do with
preprocessor" land.  Old name is #defined to __func__ to approximate the
old behaviour, but it doesn't approximate it all that well and it's really
not fit for anything but backwards compatibility in legacy code.

BTW, we used to have code that broke when gcc abandoned the old kludge -
several years ago there'd been a pile of patches fixing the resulting
turds.