Include files that depend on include files

Garance A Drosihn drosih at rpi.edu
Wed Aug 10 05:53:28 GMT 2005


At 12:22 AM +0200 8/10/05, Dirk GOUDERS wrote:
>  > This is intentational.  We try to avoid having headers bring in
>  > more then absolutly required when included.  I'm not sure what
>  > your second question means.
>
>With my second question I wanted to ask if this intention is only
>for kernel level code or a general one.  I am asking this, because
>somewhen in a project that I was not actually participating in I
>heard or read a rule that roughly said: "all include files have to
>include all files they depend on and compile cleanly", but that
>project was on a user space program.

It gets a little tricky.  POSIX rules for include files include
various requirements against "namespace pollution".  So, if you
bring in one particular include file, then you're supposed to be
confident that it will only define the symbols that you expect
from that one file.

And yet you will need to have that include file reference some
values which (according to standards) are defined by some other
standard include file.  You need one or two symbols, but you're
not allowed to define any of the other symbols.

To get around this in user-space, we do things like create
/usr/include/sys/_types.h

And then our include files include *that* file, and do not include
the standard <sys/types.h>.  This <sys/_types.h> file, in turn, does
not define any of the actual symbols.  Let's say that some include
file needs to know what typedef for 'off_t' is.  The sys/_types.h
file defines __off_t, and then the include file which needs off_t
will do something like:

#include <sys/_types.h>
#ifndef _OFF_T_DECLARED
typedef __off_t         off_t;
#define _OFF_T_DECLARED
#endif

Thus, it has only defined the one name it actually needs, instead
of defining all of the standard symbols in the real sys/types.h.

-- 
Garance Alistair Drosehn            =   gad at gilead.netel.rpi.edu
Senior Systems Programmer           or  gad at freebsd.org
Rensselaer Polytechnic Institute    or  drosih at rpi.edu


More information about the freebsd-hackers mailing list