Re: cppcheck bugs

[Csaba Raduly <rcsaba at gmail dot com>]

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.

>> [../../../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.


  if ((f = popen (buf, "rt")) == NULL)
      return;
  if (ferror (f) || feof (f) || ret == EOF || maj < 1 || min < 10)
      return; ////////// pclose is not called after successful popen, line 1159
  fclose (f); ////////// shouldn't this be pclose ? line 1161

  if ((f = popen (buf, "rt")) == NULL) // line 1168 looks consistent with below
      return;

  if (verbose)
      pclose (f);
  else
    {
      pclose (f);

      if (nchars > 0)
        for (char *srv = strtok (buf, "\n"); srv; srv = strtok (NULL, "\n"))
          {
            if ((f = popen (buf2, "rt")) == NULL)
                return;

            pclose (f);
          }
      else
        no_services = true;
    }



>> [../../../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.


-- 
Life is complex, with real and imaginary parts.
"OK, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

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