On 16-09-2012 20:57, Erik Cederstrand wrote: > Den 16/09/2012 kl. 18.05 skrev Eitan Adler <ead...@freebsd.org>: >> On 16 September 2012 10:24, Tijl Coosemans <t...@coosemans.org> wrote: >>> On 16-09-2012 01:27, Eitan Adler wrote: >>>> On 15 September 2012 17:20, Bruce Cran <br...@cran.org.uk> wrote: >>>>> On 15/09/2012 21:57, Tijl Coosemans wrote: >>>>>> Freeing memory right before exiting is a waste of time. The tool >>>>>> shouldn'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 point >>> to memory allocated by getmntinfo(3) and that manpage says an application >>> cannot free it. >> >> Ah, I missed that. I wish this point was brought up earlier. I'll >> revert the commit > > I was the one who filed the PR > (http://www.freebsd.org/cgi/query-pr.cgi?pr=171634). I'm embarrassed > to have caused a wrong commit. > > 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/report-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. > > 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).
signature.asc
Description: OpenPGP digital signature