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

James Bottomley
2008-03-30T14:08:31Z

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