[src] cvs commit: src/sys/ufs/ufs ufs_gjournal.c

[Peter Wemm]

On Mon, Apr 7, 2008 at 9:51 PM, Bruce Evans <brde at optusnet.com.au> wrote:
> On Mon, 7 Apr 2008, LI Xin wrote:
>
>
> > Picking a random commit:
> >
> >
> > >
> > >  FreeBSD src repository
> > >
> > >  Modified files:
> > >    sys/ufs/ufs          ufs_gjournal.c   Log:
> > >  Correct function name in panic().
> > >    Reported by:    kensmith
> > >    Revision  Changes    Path
> > >  1.3       +1 -1      src/sys/ufs/ufs/ufs_gjournal.c
> > >
> > >        if ((u_int)ino >= fs->fs_ipg * fs->fs_ncg)
> > > -               panic("ffs_freefile: range: dev = %s, ino = %lu, fs =
> %s",
> > > +               panic("ufs_gjournal_modref: range: dev = %s, ino = %lu,
> fs = %s",
> > >                    devtoname(dev), (u_long)ino, fs->fs_fsmnt);
> > >        if ((error = bread(devvp, cgbno, (int)fs->fs_cgsize, NOCRED,
> &bp))) {
> > >                brelse(bp);
> > >
> >
> >
> > Is it suitable to use something like __func__ here?  I mean, will the
> usage of __func__ encouraged practice for base/kernel code or not?
> >
>
>  No, __func__ is an obfuscation.  It is sort of write-only.  It should
>  only be used when the function name is not a compile-time constant
>  (mainly in macros).  Its use would be an especially large style bug
>  in ufs, since ufs consistently doesn't use it (except in 1 recently
>  broken place).
>
>  The above commit also breaks the style using blind substitution which
>  happens to expand a line beyond 80 characters.
>
>  Bruce

I tend to agree.  My own personal reason is that I tend to frequently
grep the source for printf and panic strings.  grep can't do __func__
substitution.

-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell
**WANTED TO BUY: Garmin Streetpilot 2650 or 2660. Not later model! **