On Fri, 2008-03-28 at 15:45 -0700, Andrew Morton wrote: > On Fri, 28 Mar 2008 17:35:04 -0500 > James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > On Fri, 2008-03-28 at 14:48 -0700, akpm@xxxxxxxxxxxxxxxxxxxx wrote: > > > From: Harvey Harrison <harvey.harrison@xxxxxxxxx> > > > > > > __FUNCTION__ is gcc-specific, use __func__ > > > > I thought we basically agreed > > No. OK, so what are your reasons? I've only heard the unpersuasive: > 1) Currently there is a mix of __FUNCTION__ and __func__ in the > kernel, > and __func__ is ansi C (C99...) > > 2) It's shorter > > 3) When people look around to add new code, they will only see the one > way the kernel does it. > > None of which are very convincing, but there you go. > > there was no point to this since if it > > ever became an issue you can do > > > > #define __FUNCTION__ __func__ > > > > inside the include/compiler-xxx.h file > > > > It's better to get things right at the original code site, rather than > adding crufty back-compatibility macros. What do you mean "get things right"? __FUNCTION__ isn't even deprecated in gcc (the deprecation was __FUNCTION__ string concatenation) ... there's no sign it will ever be wrong. It's also stylistically far more consonant with __FILE__ and __LINE__. > The patches are easy to prepare, easy to review and easy to merge. There's > no reason to not do so. Except for the code churn in the drivers and the merge problems it causes (The -mc tree already has this reverted in acpi to fix a merge issue). The greater issue is setting the bar too low for for mechanical changes ... what's next? C99 comments? u32 -> uint32_t ... there are tons of possible sweeping changes that could be justified on the above grounds. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
