From owner-svn-src-head@freebsd.org Tue Aug 4 11:42:36 2015 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 84B8C9B3662; Tue, 4 Aug 2015 11:42:36 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id 3E995AB2; Tue, 4 Aug 2015 11:42:35 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id DA27AD4881E; Tue, 4 Aug 2015 21:42:31 +1000 (AEST) Date: Tue, 4 Aug 2015 21:42:31 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ed Schouten cc: Bruce Evans , John-Mark Gurney , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r286170 - head/share/man/man9 In-Reply-To: Message-ID: <20150804210408.D2008@besplex.bde.org> References: <201508020022.t720MFqp023071@repo.freebsd.org> <20150802145434.V1128@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=eZjABOwH c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=kj9zAlcOel0A:10 a=WLmREnM5Lxl_QZHa9CoA:9 a=CjuIK1q_8ugA:10 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 11:42:36 -0000 On Tue, 4 Aug 2015, Ed Schouten wrote: > Hi Bruce, > > 2015-08-02 7:35 GMT+02:00 Bruce Evans : >> 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