there's a cppcheck - tool for static C/C++ code analysis...
dirk at hohndel.org
Wed Sep 19 03:24:44 PDT 2012
Cristian Ionescu-Idbohrn <cristian.ionescu-idbohrn at axis.com> writes:
> On Tue, 18 Sep 2012, Dirk Hohndel wrote:
>> Cristian Ionescu-Idbohrn <cristian.ionescu-idbohrn at axis.com> writes:
>> > ...I grew to love ;) Few false positives, IMO.
>> > After watching the "subsurface crashes on me" later mails, I thought I
>> > might just as well use it. And this is what it (v1.56) reports:
>> Wow, what a treasure trove.
> Isn't it ;} Debian (and derivatives) should have that packaged.
So does Fedora. Already installed :-)
> Besides the (style) nitpicks about reducing variables scope, I wonder
> if the recurring:
> (portability) Non reentrant function 'gmtime' called. For
> threadsafe applications it is recommended to use the
> reentrant replacement function 'gmtime_r'.
> isn't one of those things that may play tricks?
Well, we should use gmtime only from our main thread, so I don't think
that's it, but I'll implement what others suggested on the flight home
this evening (unless someone beats me to it).
> Another thing is the realloc. 'file.c:72' in particular.
> Isn't that too optimistic? I mean, shouldn't mem be checked?
I believe the realloc code to be correct in all cases except when we run
out of memory and the previous pointer isn't freed, therefore creating a
potential leak. But at that point we already ran out of memory, so I
don't think we care. I'll stare at the code some more to verify :-)
> parse-xml.c:1298]: (error) Memory leak: buf
> looks real to me.
It certainly is. But again, that wasn't my key concern last night.
Thanks again for pointing me in this direction.
More information about the subsurface