On Sun, 2 Aug 2015, John-Mark Gurney wrote:
Log: convert to C11's _Static_assert, and pull in sys/cdefs.h for compatibility w/ older non-C11 compilers...
This include is bogus. <net/pfkeyv2.h> already depends on the includer including other headers that include <sys/cdefs.h>. Mainly <sys/types.h>. <sys/types.h> defined massive namespace pollution that includes everything in <sys/cdefs.h>. It includes <sys/cdefs.h> an infinite number of times via recursion, except the recursion is stopped by anti-reinclude guards. Th recursion makes the static number of nested includes of <sys/cdefs.h> hard to count. Also, this is a kernel header. All kernel headers depend on the includer including <sys/param.h> and <sys/systm.h>. Some work accidentally without this, and broken includers depend on this. For example, this file didn't depend on <sys/systm.h> for the definition of CTASSERT() and wasn't broken when CTASSERT() was added, but if any includers of it that didn't include <sys/systm.h> had there brokenness exposed. <sys/param.h> and <sys/systm.h> defined much more massive namespace pollution than <sys/types.h>, together with some names that that are not pollution. Almost everything in <sys/cdef.h> is now part of the API. As a result, most kernel headers should not include <sys/cdefs.h>. Some leaf headers like the x86 _types.h check that it is included before them. Some headers that are intentionally shared between the kernel and userland have a sloppy but non-polluting _KERNEL section that depends on many includes (mainly all the ones in <sys/param.h> and doesn't include anything explicitly, followed by a non-sloppy userland section that begins with an include of <sys/cdefs.h>. This include used to be used for __BEGIN/__END_DECLS and __P(()) but is now just used for the former. Macros like __BEGIN/__END_DECLS and _Static_assert are just as ugly as __P(()) and should go away, but they have proliferated faster than __P(()) went away. The non-sloppyness includes not including <sys/types.h> but using basic types and declaring the few ufoo_t types that are part of the documented API of the header. If an application wants to abuse a kernel header, then it must fake the kernel environment for it. I don't know much about this header, but it is not documented in any man page so it can do anything. Bruce _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"