From owner-svn-src-head@FreeBSD.ORG Tue Sep 18 14:09:09 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA91A1065670; Tue, 18 Sep 2012 14:09:09 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay011.isp.belgacom.be (mailrelay011.isp.belgacom.be [195.238.6.178]) by mx1.freebsd.org (Postfix) with ESMTP id E939B8FC0A; Tue, 18 Sep 2012 14:09:08 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAt/WFBbsUA+/2dsb2JhbABFvDuBCYIgAQEEAVYiAQULCxgJFg8JAwIBAgEnHgYNAQUCAQEFh3EKB7o6ixuGcAOOaYEghm6PDYJo Received: from 62.64-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.64.62]) by relay.skynet.be with ESMTP; 18 Sep 2012 16:07:58 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.5/8.14.5) with ESMTP id q8IE7vrH002986; Tue, 18 Sep 2012 16:07:57 +0200 (CEST) (envelope-from tijl@coosemans.org) Message-ID: <50588037.6010009@coosemans.org> Date: Tue, 18 Sep 2012 16:07:51 +0200 From: Tijl Coosemans User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120804 Thunderbird/14.0 MIME-Version: 1.0 To: Erik Cederstrand References: <201209142347.q8ENlN7N034951@svn.freebsd.org> <5054EBCB.6070105@coosemans.org> <5054F116.8090503@cran.org.uk> <5055E121.2030208@coosemans.org> <950ECA11-BDDF-4805-AB9F-07F233A8429E@cederstrand.dk> In-Reply-To: <950ECA11-BDDF-4805-AB9F-07F233A8429E@cederstrand.dk> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig009E4C34CAAFB2C1D94D079F" Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r240527 - head/bin/df X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Sep 2012 14:09:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig009E4C34CAAFB2C1D94D079F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 16-09-2012 20:57, Erik Cederstrand wrote: > Den 16/09/2012 kl. 18.05 skrev Eitan Adler : >> On 16 September 2012 10:24, Tijl Coosemans wrote:= >>> On 16-09-2012 01:27, Eitan Adler wrote: >>>> On 15 September 2012 17:20, Bruce Cran wrote: >>>>> On 15/09/2012 21:57, Tijl Coosemans wrote: >>>>>> Freeing memory right before exiting is a waste of time. The tool s= houldn't >>>>>> complain about it. >>>> >>>> Perhaps, but tools do. This has already been brought up on cfe-dev. >>> >>> In this case the free is actually wrong, because the pointer can poin= t >>> to memory allocated by getmntinfo(3) and that manpage says an applica= tion >>> cannot free it. >> >> Ah, I missed that. I wish this point was brought up earlier. I'll >> revert the commit >=20 > I was the one who filed the PR > (http://www.freebsd.org/cgi/query-pr.cgi?pr=3D171634). I'm embarrassed > to have caused a wrong commit. >=20 > The big picture is I'm looking through the Clang Analyzer scans at > http://scan.freebsd.your.org/freebsd-head trying to find false > positives to report back to LLVM. Their PR originated in this > warning: > http://scan.freebsd.your.org/freebsd-head/bin.df/2012-09-12-amd64/repor= t-WwB2qk.html#EndPath > The scan has 326 warnings about possible memory leaks in world, so > I'd really like to do something here, be it either via bug report > with LLVM or FreeBSD or to annotate the code to say it's okay to > break the rules. >=20 > There response from LLVM (disregarding that mntbuf can't be freed) is > either that: 1) if main() is redefined as a macro, it's still a leak, If main is renamed using a macro it isn't main anymore and it's ok to complain about leaks. A more valid objection would be that main is still an ordinary function that can be called from other functions, so a memory leak there is potentially just as problematic as in any other function. But that's very theoretical. In practice I think not complaining about leaks in main by default would take out more false positives than create false negatives. > and 2) they can skip the warning only if it's feasible to reason that > prtstat() doesn't allocate memory. I don't understand why this is a requirement. If there's a call to exit(3) instead of a return statement the analyzer already doesn't seem to complain and a return from main() is the same as a call to exit() in practice. > I noticed that the sentence "The memory allocated by getmntinfo() > cannot be free(3)'d by the application." in the getmntinfo(3) manage > is in the bugs section. Does this mean it's something that should be > fixed in FreeBSD eventually? Probably not. The section could be renamed CAVEATS like basename(3). --------------enig009E4C34CAAFB2C1D94D079F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iF4EAREIAAYFAlBYgDwACgkQfoCS2CCgtitI5gD/bLujB/9Bq+5V8jV33oqIq2i7 MxTEOA0cgFXj2Tvs7/IA/3bIl9H31NooDVuGKHQ5ycHC53Pe+Y+McHTTTat0GtDb =XN7/ -----END PGP SIGNATURE----- --------------enig009E4C34CAAFB2C1D94D079F--