Date: Tue, 16 Jul 2013 10:40:59 -0400 From: John Baldwin <jhb@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> 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: <201307161040.59919.jhb@freebsd.org> In-Reply-To: <20130717001753.C2643@besplex.bde.org> References: <201307151540.r6FFewZc049719@svn.freebsd.org> <201307161002.15094.jhb@freebsd.org> <20130717001753.C2643@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, July 16, 2013 10:35:21 am Bruce Evans wrote: > 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. I would be fine by codifying this via a nested include in <sys/param.h> in the _KERNEL case of <sys/systm.h> if you think that is the best fix. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201307161040.59919.jhb>