From owner-svn-src-all@freebsd.org Fri Aug 28 20:52:56 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 D08DB9C48EC; Fri, 28 Aug 2015 20:52:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD9B388E; Fri, 28 Aug 2015 20:52:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A3D66B986; Fri, 28 Aug 2015 16:52:55 -0400 (EDT) From: John Baldwin To: cem@freebsd.org Cc: Xin LI , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r287236 - head/bin/df Date: Fri, 28 Aug 2015 13:28:48 -0700 Message-ID: <1506354.HODiTnTr7L@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <201508280044.t7S0ixfW038766@repo.freebsd.org> <55E01D9A.2090805@delphij.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 28 Aug 2015 16:52:55 -0400 (EDT) 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: Fri, 28 Aug 2015 20:52:56 -0000 On Friday, August 28, 2015 07:05:06 AM Conrad Meyer wrote: > On Fri, Aug 28, 2015 at 1:36 AM, Xin Li wrote: > > And then later assign a block of memory allocated from heap to it: > > > > p = malloc(size); > > > > Since p is in function scope, upon return, it's gone. If there is no > > other pointers that referenced the memory block referenced by p, the > > memory block is _technically_ leaked. > > > > This does not matter in practice because exit() or returning from main > > are both the points of termination, and the kernel would then reclaim > > all memory pages that belongs to the process. However, doing exit() > > makes it more explicit that this is the point of no returns, actually, > > it hints the compiler or a static analyzer to do the right thing without > > needing to make main() a special case. > > > So, a better commit log may have been: > > "Use exit() instead of return in main() to work around a broken static analyzer" > > Any C static analyzer must understand main(). +1 C++ might be another case (if you want to avoid destructors for local objects in main() for some reason, and that probably argues for preferring return over exit in general since usually you do want to run destructors). -- John Baldwin