Re: svn commit: r286170 - head/share/man/man9

[Jonathan Anderson]

> On Aug 4, 2015, at 8:18 AM, Hans Petter Selasky  wrote:
> 
> Wouldn't the argument be the same for queue.3 . Once C-compilers finally 
> decide to compile time support queues, we should throw queue.3 aswell?


Sure! Not right away, and not in a way that causes unnecessary churn, but if 
there are benefits (e.g., better optimizations, better standards compliance) 
and a diversity of compilers support a new C feature in both our stable 
branches and the ports tree (for lots of architectures), then why not?

(note: by “diversity”, I don’t mean “Clang and GCC support it on amd64 but none 
of the vendor toolchains for other important architectures do”)

There are lots of things like this, where FreeBSD folk historically said, 
“K/C89/C99/C11 doesn’t provide feature X, so we need to write some macros to 
do it ourselves.” That’s great, FreeBSD was ahead of its time, but once the C 
standard catches up, isn’t it good to hew to the standard wherever it’s 
practical to do so? stdatomic.h, _Generic, _Noreturn, static assertions... the 
language is growing lots of useful features. Wouldn’t it be good to adopt them 
when we can and trim non-standard code?

Cheers,


Jon
--
jonat...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r286170 - head/share/man/man9

[John-Mark Gurney]

Hans Petter Selasky wrote this message on Fri, Aug 21, 2015 at 08:17 +0200:
 On 08/04/15 19:10, John-Mark Gurney wrote:
  Hans Petter Selasky wrote this message on Tue, Aug 04, 2015 at 12:48 +0200:
  My gut feeling is it's good practice to have those wrapper macros
  because they isolate the compiler into a consistent and coherent API.
 
  Except that we now have a consistent and coherent API w/
  _Static_assert...  We emulate this function on all compilers (or at least
  try to, see bde's other email about issues w/ the ifdef mess), and
  is available to both userland and kernel...  It will also be available
  on other platforms, as opposed to having to port our CTASSERT macros
  to other platforms and introduce #ifdef's to make it compatible...
 
  Wouldn't the argument be the same for queue.3 . Once C-compilers finally
  decide to compile time support queues, we should throw queue.3 aswell?
  I'd say it is better to stay independent of what the compiler guys will
  come up with next, reminding me how hard it was to upgrade a machine
  recently from 9- to 10- because of C++11 
 
  Last I checked, they don't change their API's ever revision of the
  langauge...
 
  Comparing this to C++11?  Just wow, see above how this is properly
  covered by the ifdef mess in sys/cdefs.h for all compilers, this won't
  introduce any complications like the C++11...
 
 Here is one more argument against using _Static_assert():
 
 According to http://en.cppreference.com/w/c/language/_Static_assert; 
 _Static_assert is C11 syntax only, and we compile the kernel using 
 -std=iso9899:1999 according to conf/kern.mk:CFLAGS in -current. So 
 technically it shouldn't work, and it throws up compile errors with 
 certain other C tools I'm using at work which are more strict than clang.
 
 Any comments?

As stated before, cdefs.h provides glue for support for pre-C11
compilers, so I don't see a problem...  Do you have documented cases
of the glue not working on pre-C11 compilers?

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r286170 - head/share/man/man9

[Ed Schouten]

2015-08-21 8:17 GMT+02:00 Hans Petter Selasky h...@selasky.org:
 Here is one more argument against using _Static_assert():

 According to http://en.cppreference.com/w/c/language/_Static_assert;
 _Static_assert is C11 syntax only, and we compile the kernel using
 -std=iso9899:1999 according to conf/kern.mk:CFLAGS in -current. So
 technically it shouldn't work, and it throws up compile errors with certain
 other C tools I'm using at work which are more strict than clang.

In practice it does.

-- 
Ed Schouten e...@nuxi.nl
Nuxi, 's-Hertogenbosch, the Netherlands
KvK-nr.: 62051717
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r286170 - head/share/man/man9

[Hans Petter Selasky]

On 08/04/15 19:10, John-Mark Gurney wrote:

Hans Petter Selasky wrote this message on Tue, Aug 04, 2015 at 12:48 +0200:

My gut feeling is it's good practice to have those wrapper macros
because they isolate the compiler into a consistent and coherent API.


Except that we now have a consistent and coherent API w/
_Static_assert...  We emulate this function on all compilers (or at least
try to, see bde's other email about issues w/ the ifdef mess), and
is available to both userland and kernel...  It will also be available
on other platforms, as opposed to having to port our CTASSERT macros
to other platforms and introduce #ifdef's to make it compatible...


Wouldn't the argument be the same for queue.3 . Once C-compilers finally
decide to compile time support queues, we should throw queue.3 aswell?
I'd say it is better to stay independent of what the compiler guys will
come up with next, reminding me how hard it was to upgrade a machine
recently from 9- to 10- because of C++11 


Last I checked, they don't change their API's ever revision of the
langauge...

Comparing this to C++11?  Just wow, see above how this is properly
covered by the ifdef mess in sys/cdefs.h for all compilers, this won't
introduce any complications like the C++11...



Hi,

Here is one more argument against using _Static_assert():

According to http://en.cppreference.com/w/c/language/_Static_assert; 
_Static_assert is C11 syntax only, and we compile the kernel using 
-std=iso9899:1999 according to conf/kern.mk:CFLAGS in -current. So 
technically it shouldn't work, and it throws up compile errors with 
certain other C tools I'm using at work which are more strict than clang.


Any comments?

--HPS
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r286170 - head/share/man/man9

[Hans Petter Selasky]

On 08/04/15 12:03, Ed Schouten wrote:

Hi Bruce,

2015-08-02 7:35 GMT+02:00 Bruce Evansb...@optusnet.com.au:

This function shouldn't be deprecated.  It is a kernel wrapper with a
good name for hiding the implementation detail or not-yet standard
interface _Static_assert().

_Static_assert has been part of the C standard for approximately 4 years now.

I personally couldn't care less about the naming, but in a couple of
years from now we'll have an entire generation of recently graduated
computer scientists who know what _Static_assert does, because they
used it in their C/C++ programming classes. None of them know what a
'CTASSERT' is.


Hi,

Is it correct to assume that everyone doing programming has done a 
programming class of a certain kind?


My gut feeling is it's good practice to have those wrapper macros 
because they isolate the compiler into a consistent and coherent API. 
Wouldn't the argument be the same for queue.3 . Once C-compilers finally 
decide to compile time support queues, we should throw queue.3 aswell? 
I'd say it is better to stay independent of what the compiler guys will 
come up with next, reminding me how hard it was to upgrade a machine 
recently from 9- to 10- because of C++11 


--HPS
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r286170 - head/share/man/man9

[Ed Schouten]

2015-08-04 12:48 GMT+02:00 Hans Petter Selasky h...@selasky.org:
 Once C-compilers finally decide to compile time support queues, we should 
 throw queue.3 aswell?

If the API provided by the C standard would be functionally identical
and easy to emulate with older compilers (which is the case for
_Static_assert), then yes. Meaning: we should put a notice at the top
of the man page that the C standard functionality should be used
instead.

-- 
Ed Schouten e...@nuxi.nl
Nuxi, 's-Hertogenbosch, the Netherlands
KvK/VAT number: 62051717
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r286170 - head/share/man/man9

[Ed Schouten]

Hi Bruce,

2015-08-02 7:35 GMT+02:00 Bruce Evans b...@optusnet.com.au:
 This function shouldn't be deprecated.  It is a kernel wrapper with a
 good name for hiding the implementation detail or not-yet standard
 interface _Static_assert().

_Static_assert has been part of the C standard for approximately 4 years now.

I personally couldn't care less about the naming, but in a couple of
years from now we'll have an entire generation of recently graduated
computer scientists who know what _Static_assert does, because they
used it in their C/C++ programming classes. None of them know what a
'CTASSERT' is.

We constantly complain about how hard it is to attract new developers
to the project. Maybe it's because we require them to learn
nonsensical things in order to contribute code.

 CTASSERT() is the compile-time variant of KASSERT().  We intentionally
 use KASSERT() instead of anything like the standard assert(3) since
 we don't like the API or semantics of assert() and want one with
 different design and implementation bugs.  I can't think of any use
 for different semantics to _Static_assert(), but using CTASSERT()
 retains flexibility.

The problem with this reasoning is that it can be extrapolated. Why is
_Static_assert() special in this regard? Why wouldn't we then write a
wrapper around 'while' and use it all over our codebase, simply to
retain flexibility?

-- 
Ed Schouten e...@nuxi.nl
Nuxi, 's-Hertogenbosch, the Netherlands
KvK/VAT number: 62051717
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r286170 - head/share/man/man9

[Bruce Evans]

On Tue, 4 Aug 2015, Ed Schouten wrote:


Hi Bruce,

2015-08-02 7:35 GMT+02:00 Bruce Evans b...@optusnet.com.au:

This function shouldn't be deprecated.  It is a kernel wrapper with a
good name for hiding the implementation detail or not-yet standard
interface _Static_assert().


_Static_assert has been part of the C standard for approximately 4 years now.


We don't have any C11 compilers yet.  I'm still waiting for a C99 compiler
(with fenv support).


I personally couldn't care less about the naming, but in a couple of
years from now we'll have an entire generation of recently graduated
computer scientists who know what _Static_assert does, because they
used it in their C/C++ programming classes. None of them know what a
'CTASSERT' is.


I doubt that many of them will have even seen the identifier _Static_assert.
It should be taught some time after fenv, but there probably isn't time
to cover either.


We constantly complain about how hard it is to attract new developers
to the project. Maybe it's because we require them to learn
nonsensical things in order to contribute code.


CTASSERT() isn't nonsense.  It is just another special kernel API.


CTASSERT() is the compile-time variant of KASSERT().  We intentionally
use KASSERT() instead of anything like the standard assert(3) since
we don't like the API or semantics of assert() and want one with
different design and implementation bugs.  I can't think of any use
for different semantics to _Static_assert(), but using CTASSERT()
retains flexibility.


The problem with this reasoning is that it can be extrapolated. Why is
_Static_assert() special in this regard? Why wouldn't we then write a
wrapper around 'while' and use it all over our codebase, simply to
retain flexibility?


Because of portability.  The kernel can use new things like
_Static_assert() but has negative reasons to switch from its better
CTASSERT() API.  Contribed code not written for C11 should be portable
and not use it without messy ifdefs.  Current contribed code doesn't
even use it with messy ifdefs.  Its only uses in src/contrib are in
clang, llvm, once in libcxxrt, and once in top/utils.c written recently.
The latter is just a mistake.  Try getting such a change (in dusty deck
code) accepted by the vendor.  It would be easier to fix the code by
using a C99 feature (snprintf()), but that would probably be too
unportable for the vendor.  contrib_top only uses snprintf() once now,
and this is in a FreeBSD change.  Non-contribed code in userland shouldn't
abuse the kernel CTASSERT() and can reasonably use _Static_assert().

Bruce
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r286170 - head/share/man/man9

[John-Mark Gurney]

Hans Petter Selasky wrote this message on Tue, Aug 04, 2015 at 12:48 +0200:
 My gut feeling is it's good practice to have those wrapper macros 
 because they isolate the compiler into a consistent and coherent API. 

Except that we now have a consistent and coherent API w/
_Static_assert...  We emulate this function on all compilers (or at least
try to, see bde's other email about issues w/ the ifdef mess), and
is available to both userland and kernel...  It will also be available
on other platforms, as opposed to having to port our CTASSERT macros
to other platforms and introduce #ifdef's to make it compatible...

 Wouldn't the argument be the same for queue.3 . Once C-compilers finally 
 decide to compile time support queues, we should throw queue.3 aswell? 
 I'd say it is better to stay independent of what the compiler guys will 
 come up with next, reminding me how hard it was to upgrade a machine 
 recently from 9- to 10- because of C++11 

Last I checked, they don't change their API's ever revision of the
langauge...

Comparing this to C++11?  Just wow, see above how this is properly
covered by the ifdef mess in sys/cdefs.h for all compilers, this won't
introduce any complications like the C++11...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r286170 - head/share/man/man9

[Bruce Evans]

On Sun, 2 Aug 2015, John-Mark Gurney wrote:


Log:
 mark this function as deprecated, and put the warning first, since I
 doubt most people will read to the end...  Note the use of sys/cdefs.h
 for pre-C11 compilers...


This function shouldn't be deprecated.  It is a kernel wrapper with a
good name for hiding the implementation detail or not-yet standard
interface _Static_assert().

CTASSERT() is the compile-time variant of KASSERT().  We intentionally
use KASSERT() instead of anything like the standard assert(3) since
we don't like the API or semantics of assert() and want one with
different design and implementation bugs.  I can't think of any use
for different semantics to _Static_assert(), but using CTASSERT()
retains flexibility.

sys/cdefs.h isn't a prerequisite for this function.  The correct
prerequisites for this function are already documented.  They are
sys/param.h and sys/systm.h.


 I didn't included a note about being compatibile w/ userland since a
 C11 feature should be obviously usable in userland...


If CTASSERT() is abused in userland, then the kernel environment must
be faked.


Modified: head/share/man/man9/CTASSERT.9
==
--- head/share/man/man9/CTASSERT.9  Sun Aug  2 00:18:48 2015
(r286169)
+++ head/share/man/man9/CTASSERT.9  Sun Aug  2 00:22:14 2015
(r286170)
@@ -26,7 +26,7 @@
.\
.\ $FreeBSD$
.\
-.Dd July 30, 2015
+.Dd August 1, 2015
.Dt CTASSERT 9
.Os
.Sh NAME
@@ -39,6 +39,15 @@
.Sh DESCRIPTION
The
.Fn CTASSERT
+macro is deprecated and the C11 standard
+.Fn _Static_assert
+should be used instead.
+The header
+.Fa sys/cdefs.h
+should be included to provide compatibility for pre-C11 compilers.


_Static_assert() shoudn't be used instead, but when it is including
sys/cdefs.h isn' optional.  Then the documented prerequisites for this
function might not be needed for the replacement but in the kernel they
must be provided for other functions.

Some section 9 man pages, e.g., atomic.9, document a minimal
prerequisite like sys/types.h, but this sets a bad example and
inhibits adding conditional features like KASSERTS()s in atomic.h.
atomic.h is so low-level that you normally wouldn't want to bloat it
with assertions, but you might want to add them for debugging.  In
fact, it is a style bug for any kernel file to use the documented
prerequisite for the atomic functions.  machine/atomic.h is part of
the standard pollution in sys/systm.h and it is a style bug to not
depend on that.

sys/param.h is a documented prerequisite in 264 section 9 man pages
(at the source level; many more counting links).  sys/systm.h is in
only 34.  sys/types.h is in 41.


+.Pp
+The
+.Fn CTASSERT
macro evaluates
.Fa expression
at compile time and causes a compiler error if it is false.
@@ -48,10 +57,6 @@ The
macro is useful for asserting the size or alignment of important
data structures and variables during compilation, which would
otherwise cause the code to fail at run time.
-.Pp
-The
-.Fn CTASSERT
-macro is not usable in userland.


The CTASSERT() macro is still not usable in userland.  It is only abusable.
Its alternative _Static_assert() is usable, but most people won't read to
the beginning of this to find it here.


.Sh EXAMPLES
Assert that the size of the
.Vt uuid


Bruce
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org