there's a cppcheck - tool for static C/C++ code analysis...

[Dirk Hohndel]

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 :-)

> And:
>
> 	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.

/D