On 20/04/2010 15:06, Csaba Raduly wrote:
> On Tue, Apr 20, 2010 at 2:30 PM, Dave Korn wrote:
>> On 19/04/2010 22:16, Martin Ettl wrote:
>>> I used cppcheck
>>> [../machine/mips/strncpy.c:205]
>> Uhh, why is it telling us about the MIPS-only version of strncpy in newlib
>> that we don't even compile in?
>>
>
> AIUI, that's because cppcheck tries every possible combination of
> macros. Unfortunately, there doesn't seem to be a way to specify that
> a certain macro is always defined/never defined (i.e. check just one
> combination). For example, in our software we have #defines like
> WIN32, LINUX, SOLARIS, etc where only one can be defined at any one
> time. cppcheck tries every possible value and (when there are other
> macros) usually gives up because of too many different combinations.
Ah, that's a tricky one. Lint solves the problem by being able to accept
and parse both command-line -D options and preprocessing the sources it parses
using cpp in order to see the outcome of #define directives.
>
>>> [../../../winsup/utils/cygcheck.cc:1161]: (Error) Mismatching allocation
>>> and deallocation: f
>>> [../../../winsup/utils/cygcheck.cc:1168]: (Error) Mismatching allocation
>>> and deallocation: f
>>> [../../../winsup/utils/cygcheck.cc:1159]: (Error) Resource leak: f
>
> If that's dump_sysinfo_services(), then the usage looks indeed suspect to me.
But it's cygcheck: it's a one-shot executable. No matter how many file
handles and how much memory it leaks, it all gets returned to the system when
the application terminates. That's the problem with static analysis: it isn't
context-aware, so it doesn't know whether a leak is unimportant because the
program is about to exit, or significant because the program is something
long-running such as a server or daemon.
>>> [../../../winsup/cygwin/child_info.h:65]: (Error) Class child_info which is
>>> inherited by class child_info_spawn does not have a virtual destructor
>> Pretty sure it's meant to be that way for a reason.
>
> Should not be an issue unless a derived-class object is freed through
> a base-class pointer.
Yep, and that's why some of the "uses a C-style cast" warnings were also
bogus; the code knows exactly when it has a pointer to an instance of the base
class, and when it has a pointer to an instance of the derived class, and so
it knows how to destruct them appropriately.
cheers,
DaveK
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
