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"
