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

Dirk Hohndel dirk at
Wed Sep 19 03:24:44 PDT 2012

Cristian Ionescu-Idbohrn <cristian.ionescu-idbohrn at> writes:

> On Tue, 18 Sep 2012, Dirk Hohndel wrote:
>> Cristian Ionescu-Idbohrn <cristian.ionescu-idbohrn at> 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.


More information about the subsurface mailing list