svn commit: r240527 - head/bin/df

[Tijl Coosemans]

On 16-09-2012 20:57, Erik Cederstrand wrote:
> Den 16/09/2012 kl. 18.05 skrev Eitan Adler <eadler at FreeBSD.org>:
>> On 16 September 2012 10:24, Tijl Coosemans <tijl at coosemans.org> wrote:
>>> On 16-09-2012 01:27, Eitan Adler wrote:
>>>> On 15 September 2012 17:20, Bruce Cran <bruce at 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).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/svn-src-all/attachments/20120918/17c37be8/signature.pgp