Sorry about the formatting. Looks like the asterisk got eaten. That ticket looks very close to the problem I run across. Since its a regression, I'm wondering if anyone tried git bisect to locate the commit that caused it?
-Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What I found is the problem showed up on 1.82 and it was OK in 1.81. Ticket 8103 was opened before the patch that git bisect found. My guess, now that I've had time to think about it, is that it missed the allocation in 1.81 and thus no report. The patch fixes a problem to catch memory allocations but does not account for an error condition that leads to no allocation.
In doing more modelling of a bunch of linux kernel syscalls, I started to wonder if there should be some generic way to specify a return code that signals no allocation because of error? IOW, if I teach cppcheck that eventfd allocates a resource, how does it know when no allocation was made? I think that fopen could use the same mechanism to decide if an allocation was made or not.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I was doing some testing and found that 1.83 is giving a false positive for code that checks OK on 1.80. The reproducer looks like this:
On 1.80 it checks good. On 1.83 I get a message like this:
: (error) Resource leak: fp
Is this a known issue?
Thanks,
-Steve
Last edit: Steve Grubb 2018-04-24
Hi Steve, thanks for the report.
The code looks a bit broken, can you please use the code formatting syntax, for example:
You can also attach a source file to be sure nothing gets changed.
Have you searched trac already if there is a ticket for this?
I think that the ticket https://trac.cppcheck.net/ticket/8103 and the duplicate https://trac.cppcheck.net/ticket/8396 are about your reported issue.
Can you have a look at them and verify it?
Hello,
Sorry about the formatting. Looks like the asterisk got eaten. That ticket looks very close to the problem I run across. Since its a regression, I'm wondering if anyone tried git bisect to locate the commit that caused it?
-Steve
You should be able to edit the post and fix the formatting.
Maybe no one noticed that it is a regression up to now.
Hello,
Git bisect says this is the first bad commit:
94031ef11d1821c4974e859c8df7bf5f2a1727ad
-Steve
Hmm, the ticket https://trac.cppcheck.net/ticket/8103 is over three month older than the commit https://github.com/danmar/cppcheck/commit/94031ef11d1821c4974e859c8df7bf5f2a1727ad
So maybe the ticket is not really related.
What I found is the problem showed up on 1.82 and it was OK in 1.81. Ticket 8103 was opened before the patch that git bisect found. My guess, now that I've had time to think about it, is that it missed the allocation in 1.81 and thus no report. The patch fixes a problem to catch memory allocations but does not account for an error condition that leads to no allocation.
In doing more modelling of a bunch of linux kernel syscalls, I started to wonder if there should be some generic way to specify a return code that signals no allocation because of error? IOW, if I teach cppcheck that eventfd allocates a resource, how does it know when no allocation was made? I think that fopen could use the same mechanism to decide if an allocation was made or not.