cvs commit: src/sys/sys bus_private.h

Joerg Sonnenberger joerg at britannica.bec.de
Mon Mar 1 09:59:46 PST 2004


On Mon, Mar 01, 2004 at 09:44:43AM -0800, Matthew Dillon wrote:
>    This is fine, though in general it should be noted that it is better
>    for the kernel header files to use machine types from machine/stdint.h
>    so as not to create unnessary namespace pollution by requiring that
>    <sys/types> be included.  Header files would be able
>    to safely conditionally #include <machine/stdint.h> and friends without
>    polluting the namespace and thus become more self-contained.
>    (generally speaking, only sys header files and source should
>    directly include machine/ header files like that).

Not depending on sys/types.h will be very difficult and IMO pointless.
It is one of the two header files required by almost anything else
[beside sys/param.h, which includes it]. Since the most defines there
are pretty basic and standard, this should be fine. On the other hand,
using u_int_32_t just cries for breakage, since it is only defined if
!defined(_POSIX_SOURCE). "Polluting" the namespace by including stdint.h
[from sys/types.h] which defines uint32_t is no problem, since that is an
example of a type no application should redefine.

>    A good example of this would be a program that uses old-style varargs.h,
>    and we have several.  We would not want any of our header files which
>    use varargs internally to include <stdarg.h> because it would conflict
>    with programs using the old-style varargs.h, which is why they all use
>    machine/stdarg.h.

I fully agree on this. There are very few headers which can be excepted to
be included and the list of types availible from them is even shorter.

Joerg

> 					-Matt
> 					Matthew Dillon 
> 					<dillon at xxxxxxxxxxxxx>





More information about the Commits mailing list