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 <brde at 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