From owner-svn-src-all@FreeBSD.ORG Thu Mar 12 10:05:25 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 182061C8; Thu, 12 Mar 2015 10:05:25 +0000 (UTC) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id CBD83E32; Thu, 12 Mar 2015 10:05:23 +0000 (UTC) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id 9607F783378; Thu, 12 Mar 2015 21:05:20 +1100 (AEDT) Date: Thu, 12 Mar 2015 21:05:19 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Gleb Smirnoff Subject: Re: svn commit: r279764 - head/sys/vm In-Reply-To: <20150310103046.GV17947@FreeBSD.org> Message-ID: <20150312201342.W1351@besplex.bde.org> References: <201503080213.t282DlXj012465@svn.freebsd.org> <20150310100141.GS17947@FreeBSD.org> <20150310101812.GS2379@kib.kiev.ua> <20150310103046.GV17947@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=Za4kaKlA c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=6I5d2MoRAAAA:8 a=kc-W-k2yH3fbE6mVY34A:9 a=CjuIK1q_8ugA:10 Cc: Konstantin Belousov , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 10:05:25 -0000 On Tue, 10 Mar 2015, Gleb Smirnoff wrote: > On Tue, Mar 10, 2015 at 12:18:13PM +0200, Konstantin Belousov wrote: > K> On Tue, Mar 10, 2015 at 01:01:41PM +0300, Gleb Smirnoff wrote: > K> > On Sun, Mar 08, 2015 at 02:13:47AM +0000, Konstantin Belousov wrote: > K> > K> Author: kib > K> > K> Date: Sun Mar 8 02:13:46 2015 > K> > K> New Revision: 279764 > K> > K> URL: https://svnweb.freebsd.org/changeset/base/279764 > K> > K> > K> > K> Log: > K> > K> Fix function name in the panic message. > K> > > K> > Why not use "%s, __func__" always and never encounter this problem > K> > in future? > K> > K> Because you cannot grep for the panic string when __func__ is used. It would also be an an obfuscation. > Grepping for panic string doesn't work in general. Yes it does. The string just needs to be reasonably unique. Even a mispelled function name is usually unique enough. Only function names like f or printf would give too many matches. __func__ is not unique enough. Neither are short format strings like "%d, %d, %d". Longer format strings might be unique enough, but are harder to type. > A panic message > can report pointers or numbers, which make text not unique. Actually, Uniqueness is not needed. Even for a function name you would probably only type a part of the name that you hope is unique, then examine the grep output to see if more context is needed. > the messages that do report extra information are more useful. Also, I consider them as usually just bloat. Use a debugger to find more info. Unfortunately, not all users can run debuggers, and optimization is now excessive so it breaks finding variable values. > if panic string resides in the source code under several levels of > indentation, it is likely to be split into two lines. That would be another obfuscation. Much worse that using __func__. > But you can always grep for the function name and locate the panic > or KASSERT in the function manually, which isn't a big deal. And > if %s, __func__ is used, you will never get to a wrong function. Better yet, spell all function names as __func__ or "this" in comments so that they are write-only there too ;-). Even better yet, spell all function names as __func__ in calls too. Something like __func__ would work for determining the function to call only for recursive calls. __func__ itself doesn't work for that since it is a string. Determining the name of a different function is more difficult. If I knew C++, I might be able to give an example using "this". In C I don't see a better obfuscation (that can be easily written) than using macros to change hard-to-type function names like printf to that_there_func_0. The name of the current function is of course this_here_func ;-). To actually be easier to type, change to names like _0, _1, _2, etc. Bruce