From owner-svn-src-projects@FreeBSD.ORG Wed Sep 30 19:08:07 2009 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B75841065672 for ; Wed, 30 Sep 2009 19:08:07 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 44E848FC15 for ; Wed, 30 Sep 2009 19:08:06 +0000 (UTC) Received: from lstewart-laptop.caia.swin.edu.au ([64.9.241.180]) (authenticated bits=0) by lauren.room52.net (8.14.3/8.14.3) with ESMTP id n8UIloL8011390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Oct 2009 04:47:56 +1000 (EST) (envelope-from lstewart@freebsd.org) Message-ID: <4AC3A7CE.4000207@freebsd.org> Date: Wed, 30 Sep 2009 11:47:42 -0700 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.23 (X11/20090909) MIME-Version: 1.0 To: Bruce Evans References: <200909300953.n8U9r3Oo011112@svn.freebsd.org> <20090930203736.D1368@besplex.bde.org> In-Reply-To: <20090930203736.D1368@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, SPF_SOFTFAIL autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lauren.room52.net Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r197638 - projects/tcp_ffcaia2008_8.x/sys/kern X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 19:08:07 -0000 Bruce Evans wrote: > On Wed, 30 Sep 2009, Lawrence Stewart wrote: > >> Log: >> Alphabetically order includes. >> ... >> Modified: projects/tcp_ffcaia2008_8.x/sys/kern/kern_alq.c >> ============================================================================== >> >> --- projects/tcp_ffcaia2008_8.x/sys/kern/kern_alq.c Wed Sep 30 >> 08:48:59 2009 (r197637) >> +++ projects/tcp_ffcaia2008_8.x/sys/kern/kern_alq.c Wed Sep 30 >> 09:53:03 2009 (r197638) >> @@ -36,7 +36,9 @@ __FBSDID("$FreeBSD$"); >> #include "opt_mac.h" >> >> #include >> -#include >> +#include >> +#include >> +#include >> #include >> #include >> #include >> @@ -44,12 +46,9 @@ __FBSDID("$FreeBSD$"); >> #include >> #include >> #include >> -#include >> -#include >> -#include >> +#include >> ... > > should not be sorted alphabeticaly, since it declares > things like KASSERT() and (by nested includes) hundreds of inline > functions (especially ones in , > and ) which are used in many other headers. It should > be sorted immediately after where it was. Ok got it, thanks for the pointer. Everything compiled fine which is why I made the change but as you say there must be some "pollution" somewhere. Does this requirement to keep the systm.h include up top warrant a mention in style(9) or is it just something to remember? > > Mis-sorting it is sometimes masked by namespace pollution in other > headers. has the grossest namespace pollution despite > me once completely cleaning it up :-(. It now includes > and . ( is even more disgusting. It starts by > including and says that this is "/* for NULL */", despite > there being a whole header for the purpose of defining > NULL and thus avoiding namespace which would be caused by defining > NULL in a more central header, and despite it using _much_ more of > than the definition of NULL.) But most headers aren't > as bad. Thus sorting alphabetically (near the end) > rarely works, and even when it works it is fragile and will break when > a header sorted before it starts using KASSERT(). Random, likely naive thought: is there some way to detect if a header has been included before or after another header? Could be done fairly easily with an external script I guess, but something explicit in the files (some sort of preprocessor and macro magic?) would be more useful I suspect. Perhaps there could be a warning emitted if ordering is violated or an include is detected that shouldn't be there. If done right, it would likely do the job of educating people about correct ordering/inclusion and go a long way to reducing "pollution creep". Cheers, Lawrence