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

Andrew Morton
2008-03-30T15:07:53Z

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.