Re: [patch 08/17] scsi: replace remaining __FUNCTION__ occurrences

[Andrew Morton <akpm@linux-foundation.org>]

On Sun, 30 Mar 2008 09:08:27 -0500 James Bottomley <James.Bottomley@HansenPartnership.com> 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@HansenPartnership.com> wrote:
> > 
> > > On Fri, 2008-03-28 at 14:48 -0700, akpm@linux-foundation.org wrote:
> > > > From: Harvey Harrison <harvey.harrison@gmail.com>
> > > > 
> > > > __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.