From owner-svn-src-all@freebsd.org Sun Aug 30 17:02:58 2015 Return-Path: Delivered-To: svn-src-all@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 3D7CE9C5460 for ; Sun, 30 Aug 2015 17:02:58 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CCFB21066 for ; Sun, 30 Aug 2015 17:02:57 +0000 (UTC) (envelope-from joerg@britannica.bec.de) X-RZG-AUTH: :JiIXek6mfvEEUpFQdo7Fj1/zg48CFjWjQv0cW+St/nW/auYssSp3lvLxwWP2 X-RZG-CLASS-ID: mo00 Received: from britannica.bec.de (ip-2-207-14-72.web.vodafone.de [2.207.14.72]) by smtp.strato.de (RZmta 37.11 DYNA|AUTH) with ESMTPSA id 401741r7UH2s8bW (using TLSv1 with cipher AES256-SHA (256 bits)) (Client did not present a certificate) for ; Sun, 30 Aug 2015 19:02:54 +0200 (CEST) Received: by britannica.bec.de (sSMTP sendmail emulation); Sun, 30 Aug 2015 19:02:53 +0200 Date: Sun, 30 Aug 2015 19:02:53 +0200 From: Joerg Sonnenberger To: svn-src-all@freebsd.org Subject: Re: svn commit: r287217 - head/usr.sbin/syslogd Message-ID: <20150830170253.GC7574@britannica.bec.de> 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.23 (2014-03-12) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2015 17:02:58 -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. I disagree that optimisation is the primary design goal. Static analysis and optimisation just have a huge overlap in this area. > 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. That makes no sense. The presence of the attribute allows the compiler to *ensure* that the function really does not return. Having done this in NetBSD, I can assure you that there are often enough cases where the compiler can not figure it out automatically, especially if the attribution is missing on some function pulled in externally. GCC at least up to 4.8 has not warned about such cases and I have multiple bugs where function *could* fall through. Joerg