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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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.


> > 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