From owner-freebsd-arch@FreeBSD.ORG Tue Apr 8 08:42:43 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44604106564A; Tue, 8 Apr 2008 08:42:43 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id B9D1A8FC13; Tue, 8 Apr 2008 08:42:42 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m384prPr009919; Tue, 8 Apr 2008 14:51:53 +1000 Received: from c220-239-252-11.carlnfd3.nsw.optusnet.com.au (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m384pUqJ017723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Apr 2008 14:51:35 +1000 Date: Tue, 8 Apr 2008 14:51:30 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: d@delphij.net In-Reply-To: <47FA6833.8080904@delphij.net> Message-ID: <20080408142942.B18072@delplex.bde.org> References: <20080407181250.6733810656C9@hub.freebsd.org> <47FA6833.8080904@delphij.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: delphij@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [src] cvs commit: src/sys/ufs/ufs ufs_gjournal.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2008 08:42:43 -0000 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