svn commit: r253367 - in head/sys: i386/i386 mips/mips powerpc/powerpc sparc64/sparc64

Bruce Evans brde at optusnet.com.au
Tue Jul 16 14:35:35 UTC 2013


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


More information about the svn-src-head mailing list