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. - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
