Date: Fri, 28 Aug 2015 13:28:48 -0700 From: John Baldwin <jhb@freebsd.org> To: cem@freebsd.org Cc: Xin LI <delphij@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r287236 - head/bin/df Message-ID: <1506354.HODiTnTr7L@ralph.baldwin.cx> In-Reply-To: <CAG6CVpXWTcP_%2Bv60Bj-1T=fbissT_rH8YvYeOHzBozr-gFCJ8w@mail.gmail.com> References: <201508280044.t7S0ixfW038766@repo.freebsd.org> <55E01D9A.2090805@delphij.net> <CAG6CVpXWTcP_%2Bv60Bj-1T=fbissT_rH8YvYeOHzBozr-gFCJ8w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, August 28, 2015 07:05:06 AM Conrad Meyer wrote: > On Fri, Aug 28, 2015 at 1:36 AM, Xin Li <delphij@delphij.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1506354.HODiTnTr7L>