From owner-freebsd-ports@FreeBSD.ORG Thu Jan 24 16:00:23 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E50A35EF for ; Thu, 24 Jan 2013 16:00:23 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 3988118E for ; Thu, 24 Jan 2013 16:00:22 +0000 (UTC) Received: (qmail 20784 invoked by uid 89); 24 Jan 2013 16:00:15 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@194.97.158.66) by mail.grem.de with ESMTPA; 24 Jan 2013 16:00:15 -0000 Date: Thu, 24 Jan 2013 17:00:14 +0100 From: Michael Gmelin To: Dag-Erling =?UTF-8?B?U23DuHJncmF2?= Subject: Re: Using bidirectional authentication in pkgng Message-ID: <20130124170014.57c5fa1a@bsd64.grem.de> In-Reply-To: <86libitxit.fsf@ds4.des.no> References: <20130118035721.283135fb@bsd64.grem.de> <50F9B6CC.3040303@infracaninophile.co.uk> <20130122193035.4c51be04@bsd64.grem.de> <20130123004147.GG27275@ithaqua.etoilebsd.net> <86d2wuvrjg.fsf@ds4.des.no> <20130124121942.07436be3@bsd64.grem.de> <86r4lau2wh.fsf@ds4.des.no> <20130124151629.588c33c8@bsd64.grem.de> <86libitxit.fsf@ds4.des.no> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 16:00:24 -0000 On Thu, 24 Jan 2013 16:23:54 +0100 Dag-Erling Sm=C3=B8rgrav wrote: > but Emacs will still misindent continuation lines in some cases, > e.g. when a line break occurs within nested parentheses; AFAICT from > the documentation, there is no way to tune that. Hm, so this will probably get me again, but thanks for the mode, it will certainly help. >=20 > I wrap comments at 74, and *try* to keep code closer to 74 than 80. >=20 > Some of the code in http.c is so deeply nested that it is almost > impossible to stay within 80 characters. This is a clear sign that > the code needs to be rewritten. Ok, is that only for libfetch or for all of kernel (just for future reference). >=20 > BTW, you'd have an easier time avoiding long lines if you used shorter > function and variable names and assigned commonly used expressions to > temporary variables, e.g. (matcheslen - (firstmatchdot - matches) in > fetch_ssl_hostname_match(). That's true, I'm just used to really long identifiers from work and wanted to make sure it's relatively easy to read the algorithm (well, the lack of temporaries makes it harder to read again I admit). >=20 > > > - You declare variables inside blocks, and declarations in > > > general are not properly sorted. > > I wasn't aware that this is not allowed (it's such an incredibly > > useful feature to me). >=20 > s/not allowed/strongly discouraged/ Ah ok. I don't have many of those though. >=20 > > Could you point me to the section in style(9) that specifies this > > (couldn't find it)? >=20 > Parts of a for loop may be left empty. Do not put declarations > inside blocks unless the routine is unusually complicated. Thanks. >=20 > > The closest we have is mdoc(7). I'm not sure where / whether the > requirement to start sentences on a new line is documented, but this > is actually a feature of *roff rather than a style issue; it has to > be able to tell the difference between the period that follows an > abbreviation and the period at the end of a sentence. For the same > reason, Emacs will never insert a line break after a period followed > by a single space when wrapping text. >=20 > DES Thanks for the detailed explanation. So do you think you could fix these style issues yourself, or should I give it a shot (I'm certain I will miss *some* of those issues but it will definitely get better). Cheers, --=20 Michael Gmelin