On Sun, 30 Mar 2008 09:08:27 -0500 James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > 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. > That's four reasons. > > > > 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__. That's a bug. __FILE__ and __LINE__ are preprocessor variables. __FUNCTION__ is not. > > 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. If merge problems are preventing scsi (and only scsi) from being able to handle trivial cleanups then _that_ is what should be fixed, rather than avoiding the cleanups. -- 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
