Re: svn commit: r286168 - head/sys/net

2015-08-02 Thread David Chisnall
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

2015-08-02 Thread Ian Lepore
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

2015-08-02 Thread Bjoern A. Zeeb

> 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

2015-08-01 Thread John-Mark Gurney
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

2015-08-01 Thread Bruce Evans

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"