From owner-svn-src-head@freebsd.org Sun Aug 30 12:07:21 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 485EB9C6D77; Sun, 30 Aug 2015 12:07:21 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F8E5F82; Sun, 30 Aug 2015 12:07:21 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 473713592E1; Sun, 30 Aug 2015 14:07:18 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 0530B28494; Sun, 30 Aug 2015 14:07:18 +0200 (CEST) Date: Sun, 30 Aug 2015 14:07:17 +0200 From: Jilles Tjoelker To: Ed Schouten Cc: Joerg Sonnenberger , Bruce Evans , Xin LI , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers Subject: Re: svn commit: r287217 - head/usr.sbin/syslogd Message-ID: <20150830120717.GA65410@stack.nl> References: <201508271811.t7RIB0xl077002@repo.freebsd.org> <20150828215109.G1227@besplex.bde.org> <20150828143847.GA24222@britannica.bec.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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: Sun, 30 Aug 2015 12:07:21 -0000 On Sun, Aug 30, 2015 at 11:53:00AM +0200, Ed Schouten wrote: > 2015-08-28 16:38 GMT+02:00 Joerg Sonnenberger : > > But the compiler can't tell if it is the *intention* that the function > > never returns. The warning behavior exists because that can easily > > change with macros etc. > I think it's important to keep in mind what this keyword was designed for. > The idea behind this attribute (and the C11 _Noreturn keyword) is to > allow for propagation of optimisation state across compilation units. > You use it to annotate functions in header files, so that the compiler > does not need to handle function return at the call site. This > knowledge can be automatically be inferred if the function is static. Although you are right philosophically, in practice there are some compilers and static analyzers that do benefit from noreturn attributes on static functions. In particular, gcc 4.2.1 generates better code and fewer warnings if static functions are annotated with noreturn if appropriate, and some versions of the Clang/LLVM static analyzer do not do any cross-procedural analysis at all and depend on noreturn attributes on static functions to avoid false positives. > Whether the compiler can throw additional warnings or not based on > whether this keyword is present or what the intent of the programmer > is, is completely irrelevant. In practice this means that many compiler warnings need to be disabled for the affected compilers. > I agree with Bruce that this change makes little sense. I would even > go as far as to say that GCC/Clang should just throw warnings if > _Noreturn is used on a function that is static or used on a definition > instead of a declaration. _Noreturn on a global definition makes no sense but on a static function it may still be needed. -- Jilles Tjoelker