Date: Wed, 17 Jul 2013 00:35:21 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, "Andrey V. Elsukov" <ae@freebsd.org>, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r253367 - in head/sys: i386/i386 mips/mips powerpc/powerpc sparc64/sparc64 Message-ID: <20130717001753.C2643@besplex.bde.org> In-Reply-To: <201307161002.15094.jhb@freebsd.org> References: <201307151540.r6FFewZc049719@svn.freebsd.org> <201307161002.15094.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 16 Jul 2013, John Baldwin wrote: > On Monday, July 15, 2013 11:40:58 am Andrey V. Elsukov wrote: >> Log: >> Include sys/systm.h after sys/param.h. >> >> Suggested by: pluknet > > Does this fix something? Style bugs at least. sys/systm.h defines APIs which may be used in other headers (in inline functions, typically for KASSERT(); otherwise the order is not so important). Sometimes no other header included by the file has such uses at the time that the include of sys/systm.h is sorted. Then a sorting error is just a style bug. It may become a bug later when one of the other included headers grows a dependency on sys/systm.h. > The normal style rule IIUC is to put <sys/types.h> or <sys/param.h> first, > and then to sort alphabetically. The normal style rule doesn't apply to sys/systm.h. It is almost as much a prerequisite for everything in the kernel as sys/param.h. Explicitly including sys/types.h at all in kernel files is normally at least a style bug. If sys/systm.h is included too, then it is just a style bug to include both explicitly. Otherwise, sys/types.h only works if no other header included by the file has any dependencies on sys/systm.h (or if one of the other headers satisifies such dependencies for itself and for later includes by a polluting nested include of sys/systm.h). Now almost any use of an API in sys/systm.h gives a dependency (for example, use of KASSERT() in another macro and not in an inline function gives a dependency). As for misordered includes of sys/systm.h, this may change from a style bug to a bug later if one of the other included headers grows a dependency on sys/systm.h. Now it may also change from a style bug to a bug later in more cases when pollution is removed from one of the other headers. sys/systm.h should probably be standard pollution in sys/param.h. Then explicitly including it at all would be a style bug, lile explicitly including one of the other headers that are standard pollution in sys/param.h. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130717001753.C2643>