From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 18:19:02 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B757E1065678 for ; Sat, 2 May 2009 18:19:02 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id E94078FC1C for ; Sat, 2 May 2009 18:19:01 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 02 May 2009 18:18:59 -0000 Received: from p54A3DE1D.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.222.29] by mail.gmx.net (mp006) with SMTP; 02 May 2009 20:18:59 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX18P8bRKzukPjbnhb/ln+e9xpOvDsskFcb3SE7rruY ACtdgQp5OgfVWS Message-ID: <49FC8E92.1090207@gmx.de> Date: Sat, 02 May 2009 20:18:58 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Julian Elischer References: <49F4070C.2000108@gmx.de> <20090502073658.GA65633@walton.maths.tcd.ie> <49FC752D.5080807@elischer.org> <49FC8574.5060205@gmx.de> <49FC8920.6050408@elischer.org> In-Reply-To: <49FC8920.6050408@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Cc: Maxim Sobolev , FreeBSD Hackers , Roman Divacky , Ed Schouten , David Malone , Warner Losh Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 18:19:03 -0000 Julian Elischer schrieb: > Christoph Mallon wrote: >> variables. Sorting them in a beneficial way for space efficiency is >> better left to them (and it is a rather trivial thing to do). Also you >> cannot control if more spill slots have to be inserted or some values >> do not live in memory at all, so only the compiler can determine, >> which order is best. >> But a compiler can do more: It could coalesce the space of variables >> with disjoint life ranges. But this is much harder, because you have >> to properly determine the life ranges. Finding an arbitrary >> overestimation is easy, but the fun starts when looking at called >> functions, which get passed addresses of local variables. Also finding >> an optimal coalescence for known life ranges is NP-complete in the >> general case. But that's another story. (: > > re-using space or having block-local variables means that when you > are in the debugger, you can not look at the final value that > a variable had when you left (unexpectedly) the block. This can > be a pain in the neck. (but only a debugging feature) I'm talking about an optimized build - no matter what the style of the original source was, you will have a hard time debugging it. >>>>>> +Prefer initializing variables right at their declaration. >>>> >>> >>> I have gone the other way on this. Unless 'const' is being used I >>> find I prefer to see them separately initialized. >> >> So you like hunting in multiple places instead of having both type and >> value conveniently in one place? > > Actually.. yes So at the one hand you argue that hunting things is bad, but at the same time you prefer it? I am confused. > unconditional initialization is right at the top, AFTER the blank line. > Conditional initialization must of course come after the condition, and > can not be in the same line as the declaration anyhow. It is perfectly valid to do so. Warner presented a simple example. You just have to limit the scope of the variable, which is a good for other reasons, which were explained, too. >>>>>> +Do not reuse the same variable in a different context, delare a >>>>>> new variable. >>>> >>>> I buy this largely - though it should be applied with common sense >>>> as usual. >>> >>> hmm. I think an exception might be made for our old friends i,j,k >> >> Especially they should be declared right where they are needed. C99 >> even conveniently allows the iterator variable to be declared in the >> first part of a for-loop: for (int i = 0; i != n; ++i) { ... }. By >> limiting their scope, this prevents accidently re-using stale values >> in a different place or other mistakes like the following: >> int i, j; >> for (i = 0;; ++i) { >> for (i = 0;; ++i) { >> /* oops, but compiler is happy */ >> } >> } >> for (j = 0;; ++j) { >> /* more */ >> } >> vs. >> for (int i = 0;; ++i) { >> for (int i = 0;; ++i) { >> /* warning about shadowed variable */ >> } >> } >> for (int j = 0;; ++j) { >> /* more */ >> } > > while tempting, I can't see that hapenning.. > > it stops teh following: > > > for (;;) { > blah > if (foo) > break; > } > if (i == end_condition) { > then we didn't break out; > } You reject a common case because of one special case? This is sad. (Also there are multiple ways to resolve this nicely, e.g. split the loop into a function or invert the condition and restructure the code slightly) >>>>>> -Use ANSI function declarations unless you explicitly need K&R >>>>>> compatibility. >>>>>> +Use ANSI function declarations. >>>> >>> >>> Everyone shuld be doing that already. >>> In new code, and in old code that they touch. >> >> So, is this pro or contra removing the K&R-clause? > > K&R code should be changed as part of related changes if possible. > A sweep to change a whole file is probably also ok. > changing them one at a time is probably not ok. But this is what actually is practiced. You still did not answer my question: Do you agree to remove the clause so no new old style declarations may be added? Christoph