From owner-svn-src-all@FreeBSD.ORG Fri Aug 13 10:50:14 2010 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B46C41065696; Fri, 13 Aug 2010 10:50:14 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.freebsd.org (Postfix) with ESMTP id 455008FC1A; Fri, 13 Aug 2010 10:50:13 +0000 (UTC) Received: from c122-106-147-41.carlnfd1.nsw.optusnet.com.au (c122-106-147-41.carlnfd1.nsw.optusnet.com.au [122.106.147.41]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o7DAoAHi011232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Aug 2010 20:50:12 +1000 Date: Fri, 13 Aug 2010 20:50:10 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Jung-uk Kim In-Reply-To: <201008121335.05300.jkim@FreeBSD.org> Message-ID: <20100813202748.A12838@delplex.bde.org> References: <201008121613.o7CGDOij028986@svn.freebsd.org> <201008121335.05300.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1729706536-1281696610=:12838" Cc: svn-src-head@FreeBSD.org, mdf@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r211228 - head/sys/kern X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 13 Aug 2010 10:50:14 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1729706536-1281696610=:12838 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 12 Aug 2010, Jung-uk Kim wrote: > On Thursday 12 August 2010 12:37 pm, mdf@FreeBSD.org wrote: >> On Thu, Aug 12, 2010 at 9:13 AM, Jung-uk Kim > wrote: >>> Log: >>> =A0Provide description for 'machdep.disable_rtc_set' sysctl. >>> =A0Clean up style(9) =A0nits. =A0Remove a redundant return statement >>> and an unnecessary variable. Some mailer mangled the whitespace, so the source code was unreadable and had syntax errors (hard \xa0's) in it. The hard \xa0's even got into the plain text in the log message. > --- >8 SNIP!!! --- >8 --- > >> While the device_printf() is a single statement, it spans multiple >> lines. It seems in this instance that clarity is preserved better >> by using braces even though not required by C. >> >> Quoting style(9): >> >> Space after keywords (if, while, for, return, switch). No braces >> ('{' and '}') are used for control statements with zero or only a >> single statement unless that statement is more than a single line >> in which case they are permitted. >> >> So both styles are accepted, and I would think that changing this >> is needless code churn. The main style bug here is the use of C90 string concatenation to obfuscate (not very long) messages. Some of the messages fit on 1 line before device_printf() and syslogd add prefixes to them, but the literal parts of them are misformatted across 3 lines in the source code. I try to keep messages shorted so that they fit in 1 line with normal indentation, or outdent long ones so that they fit in 1 line with abnormal indentation. > Some times it is very hard to read code when if statements contain > excessive braces and 'else' statements although is permitted by > style(9). It was one of those cases. Please note a 'else' block was > also removed from there. I agree, but don't mind the braces here. Removing the else block makes the misformatting of a string across 3 lines of source more bogus than before, since after reducing the indentation its lines are now split too early, and without splitting too early the ugly split string would fit in only 2 lines. I noticed 1 other unfixed style bug on a changed line: the SYSCTL_INT() was split much earlier than necessary (before CTLFLAG*). Now it is split as late as possible (after the variable name, which is next after CTLFLAG*). But SYSCTL_INT() is conventionally always split after CTLFLAG* unless this would give a too-long line. Bruce --0-1729706536-1281696610=:12838--