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