From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 20:32:26 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 E196610656A8 for ; Fri, 1 May 2009 20:32:26 +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 420768FC17 for ; Fri, 1 May 2009 20:32:25 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 01 May 2009 20:32:24 -0000 Received: from p54A3F073.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.240.115] by mail.gmx.net (mp069) with SMTP; 01 May 2009 22:32:24 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+FxJQjFxKFpONrnRjRUsP5ccuf4FXm7LJ+lhA/HF rz9+uHCagXoAQI Message-ID: <49FB5C57.6050407@gmx.de> Date: Fri, 01 May 2009 22:32:23 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Zaphod Beeblebrox References: <49F4070C.2000108@gmx.de> <20090428114754.GB89235@server.vk2pj.dyndns.org> <20090430.090226.1569754707.imp@bsdimp.com> <49FA8D73.6040207@gmx.de> <49FAB322.9030103@elischer.org> <5f67a8c40905011324s2ad5e02dy47c73ae950845b54@mail.gmail.com> In-Reply-To: <5f67a8c40905011324s2ad5e02dy47c73ae950845b54@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Cc: freebsd-hackers@freebsd.org, Julian Elischer 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: Fri, 01 May 2009 20:32:27 -0000 Zaphod Beeblebrox schrieb: > On Fri, May 1, 2009 at 4:30 AM, Julian Elischer wrote: > >> As an old-fart I have found many cases where what I thought was >> a silly style rule, turned out to save my work in some way. >> >> Christoph Mallon wrote: >> >> >> >>>> struct foo *fp; >>>> struct bar *bp; >>>> >>>> fp = get_foo(); >>>> if (!fp) return; >>>> bp = fp->bp; >>>> >>>> this can't easily be translated to the more natural: >>>> >>>> struct foo *fp = get_foo(); >>>> struct bar *bp = fp->bp; >>>> >> Well more natural for you, but not necessarily for everyone, >> and NOT the same as what is there now, as you noticed. >> >> >> >>>> since really you'd want to write: >>>> >>>> struct foo *fp = get_foo(); >>>> if (!fp) return; >>>> struct bar *bp = fp->bp; >>>> >>>> which isn't legal in 'C'. However, we have enough where this isn't >>>> >>> You're mistaken, this is perfectly legal C. See ISO/IEC 9899:1999 (E) >>> §6.8.2:1. In short: you can mix statements and declarations. >>> > Sure, but it's still very bad: If I'm not mistaken, this would mean that > "bp" would only be valid within the "if" clause --- which isn't very useful. You are mistaken. Re-read the "if": It already contains a "return;" as then-part. The declaration of "bp" has no relation to the "if". In fact this is very good: "bp" can only be used after the "if", because it is declared after it. Further, it most probably is only assigned a value once, so declaration and the signle assignment are in the same place, which aids readability and makes the code more concise. Christoph