Re: svn commit: r286168 - head/sys/net
On 2 Aug 2015, at 17:34, Ian Lepore wrote: > > It generates a compiler error, so the output is going to contain > file-and-line like any other compiler error, as well as the message from > the source code. It will, of course, vary between compilers, but this is what clang generates: $ cat static.c _Static_assert(0, "example assert failed"); $ cc static.c static.c:1:1: error: static_assert failed "example assert failed" _Static_assert(0, "example assert failed"); ^ ~ 1 error generated. GCC 4.8 and later produce very similar output: $ gcc-4.8 static.c static.c:1:1: error: static assertion failed: "example assert failed" _Static_assert(0, "example assert failed"); ^ gcc 4.7 only provides the first line: $ gcc-4.7 static.c static.c:1:1: error: static assertion failed: "example assert failed" David ___ 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"
Re: svn commit: r286168 - head/sys/net
On Sun, 2015-08-02 at 11:42 +, Bjoern A. Zeeb wrote: > > On 02 Aug 2015, at 00:15 , John-Mark Gurney wrote: > > -CTASSERT(sizeof(struct sadb_x_policy) == 16); > > +_Static_assert(sizeof(struct sadb_x_policy) == 16, "struct size mismatch"); > > > If this fires, how does it look like? I am assuming the string at the end is > the error message? If so and if the assertion is not printed that string > should be improved rather than being the same for all checks. > > /bz > It generates a compiler error, so the output is going to contain file-and-line like any other compiler error, as well as the message from the source code. -- Ian ___ 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"
Re: svn commit: r286168 - head/sys/net
> On 02 Aug 2015, at 00:15 , John-Mark Gurney wrote: > -CTASSERT(sizeof(struct sadb_x_policy) == 16); > +_Static_assert(sizeof(struct sadb_x_policy) == 16, "struct size mismatch"); If this fires, how does it look like? I am assuming the string at the end is the error message? If so and if the assertion is not printed that string should be improved rather than being the same for all checks. /bz ___ 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"
Re: svn commit: r286168 - head/sys/net
Bruce Evans wrote this message on Sun, Aug 02, 2015 at 14:10 +1000: > 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. already depends on the includer > including other headers that include . Mainly . > defined massive namespace pollution that includes everything > in . It includes 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 > hard to count. I'll test w/o sys/cdefs.h and if it compiles, I'll remove it... > Also, this is a kernel header. All kernel headers depend on the includer Except it isn't just a kernel header as we found out, otherwise CTASSERT would have been perfectly fine... It defines an API between kernel and userland for adding and changing the kernel SA/SP database... See sbin/setkey and lib/libipsec... [comments about kernel only headers deleted] > 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. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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"
Re: svn commit: r286168 - head/sys/net
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. already depends on the includer including other headers that include . Mainly . defined massive namespace pollution that includes everything in . It includes 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 hard to count. Also, this is a kernel header. All kernel headers depend on the includer including and . Some work accidentally without this, and broken includers depend on this. For example, this file didn't depend on for the definition of CTASSERT() and wasn't broken when CTASSERT() was added, but if any includers of it that didn't include had there brokenness exposed. and defined much more massive namespace pollution than , together with some names that that are not pollution. Almost everything in is now part of the API. As a result, most kernel headers should not include . 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 and doesn't include anything explicitly, followed by a non-sloppy userland section that begins with an include of . 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 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"