Date: Tue, 8 Apr 2008 14:51:30 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: d@delphij.net Cc: delphij@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [src] cvs commit: src/sys/ufs/ufs ufs_gjournal.c Message-ID: <20080408142942.B18072@delplex.bde.org> In-Reply-To: <47FA6833.8080904@delphij.net> References: <20080407181250.6733810656C9@hub.freebsd.org> <47FA6833.8080904@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080408142942.B18072>