On Tue, 29 Oct 2002 17:51:11 +0200 Muli Ben-Yehuda <mulix@actcom.co.il> wrote: > On Tue, Oct 29, 2002 at 11:35:40AM +0100, Jan Hudec wrote: > > On Mon, Oct 28, 2002 at 12:47:30PM -0800, Nat Ersoz wrote: > > > > > > > AFAIK it's __FUNCTION__ itself that's depreciated, since someone > > added it in recent C specification in lowercase (to be more That someone would be the ISO/IEC JTC1/SC22/WG14 working group. > > consistent with__LINE__ and __FILE__). Irony here is inappropriate, __LINE__ and __FILE__ are entirely in the scope of the preprocessor, while __FUNCTION__ and __func__ are entirely outside the scope of the preprocessor, thus they represent information of different categories, one more concerned with "packaging" the source, the other bearing language semantics. Also, while __LINE__ and__FILE__ are macros, __func__ is not, thus it is the right thing to additionally emphasize the difference by different naming. > IIRC, it's both __FUNCTION__ and string concatenation that's > deprecated. __FUNCTION__ is supposed to be replaced by __func__, but > since older gcc's don't support it and the gcc folks will continue to > support __FUNCTION__ indefinitely (or so has been said on lkml), the > kernel will continue to use __FUNCTION__. There's absolutely no reason to use __FUNCTION__ over __func__, when concatenation moves from "deprecated" to "not supported". Note that one sunny day the "support" for __FUNCTION__ may consist solely of a ``-D__FUNCTION__=__func__'' in the spec file. ~velco -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
