Re: kern/46557: sys/syslog.h can't be compiled on its own with -D_KERNEL

[Richard Hansen <rhansen%bbn.com@localhost>]

The following reply was made to PR kern/46557; it has been noted by GNATS.

From: Richard Hansen <rhansen%bbn.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/46557: sys/syslog.h can't be compiled on its own with
 -D_KERNEL
Date: Wed, 9 Sep 2015 18:34:02 -0400

 On 2015-09-09 02:25, David Holland wrote:
 > I agree that expecting <sys/types.h> first is suboptimal. However,
 > it's a bigger problem than just one header file; and adding
 > <sys/types.h> indiscriminately runs the risk of polluting the user
 > namespace in violation of POSIX and ISO C;
 
 Thank you for the detailed explanation of the surrounding issues, and
 how this isn't a trivial matter.
 
 > it has to wait until we've migrated to a source control system that
 > tracks file renames.  And that remains problematic.
 
 :(  The lack of an official Git repository is one of the reasons why I
 haven't contributed as much as I could have.
 
 On 2015-09-09 02:37, dholland%NetBSD.org@localhost wrote:
 > My inclination is to keep this open and mark it suspended until we can
 > undertake such a cleanup.  Is that ok?
 
 Sounds good to me.
 
 On 2015-09-09 07:31, Christos Zoulas wrote:
 > I don't think that such undertaking is worth-while
 
 This undertaking would be a huge time sink with no short-term gain, but
 there is long-term value:  You'd have code that is more
 readable/understandable by potential new contributors.
 
 > since none of the kernel headers are documented to be standalone.
 
 Nowadays the expectation in the broader C community is that headers are
 standalone.  Headers that aren't standalone need to be documented as
 such, not the other way around.
 
 > If you do that then you will end up including <sys/systm.h>
 > <sys/types.h> <sys/param.h> <sys/ansi.h> <sys/proc.h> from a lot of
 > places and this will happen over and over again for each header in
 > the source file.
 
 I don't see how that's a problem.  Include guards prevent duplicate
 inclusions from being noticed by the compiler.
 
 > Also if you do that you should clean the userland visible
 > headers to avoid duplicate inclusions for efficiency.
 
 Would the performance hit be noticeable?  I suspect the overhead of
 processing include guards and skipping lines of input code is orders of
 magnitude less than the work of compiling the resulting preprocessed code.
 
 > It is not like if you fix it once, it will stay fixed since there is
 > no harness to check that each header is compilable standalone (but
 > you will need to write one too).
 
 For this reason I have the following personal policy that I try to
 impose on anyone that will listen:
 
     For every header file, there is a compiled .c file that includes
     the header file *first*.  This is true even if the .c file does
     nothing other than include the header file.
 
 If this policy is religiously followed, every header file is guaranteed
 to be standalone.
 
 -Richard