automated cppcheck for gnupg

[Werner Koch]

On Tue, 15 Apr 2014 21:05, hans at guardianproject.info said:

> libgcrypt/tests/rsacvt.c:426
> 	resourceLeak	Resource leak: input

Who cares, it is short running test program.

> libgcrypt/src/hmac256.c:510
> 	deallocDealloc	Deallocating a deallocated pointer: hd

Just checked it.  It is pretty clear the HD is initialzied and has not
been deinitialized.  But please prove me wrong.

> libksba/src/cert.c:447
> 	nullPointer	Possible null pointer dereference: cert - otherwise it is
> redundant to check if cert is null at line 445

Good catch.  However, it is questionanble whether the extra check is
usefull at all.  The fucntion is only specified if a cert object is
passed.  I'll fix it anyway.

> libgcrypt/cipher/test-getrusage.c:49
> 	wrongPrintfScanfArgNum	fprintf format string has 7 parameters but only 0 are

Unfinished code from 2007 - the file is not even used.  I'll fix it, though.

> libgcrypt/cipher/md.c:1251
> 	nullPointer	Possible null pointer dereference: spec -
> 	otherwise it is redundant to check if spec is null at line 1247

Actually this is a failsafe check, but right, it should be correct.

> libgcrypt/cipher/md.c:976

> 	nullPointer Possible null pointer dereference: r - otherwise it
>       is redundant to check if r is null at line 971

Code not found.


> libassuan/src/assuan.c:136
> 	nullPointer	Possible null pointer dereference: ctx - otherwise it is
> redundant to check if ctx is null at line 135

A bit hairy to fix.  I'll postpone it to tomorrow.

> gpgme/tests/gpg/t-eventloop.c:82
> 	autoVariables	Assigning address of local auto-variable to a function parameter.

That looks okay.  The variable aliases a function parameter.

> gpgme/src/w32-io.c:797
> 	memleak	Memory leak: ctx

Leaking in a out of resource case.  Fixed.

> gpgme/src/w32-util.c:713
> 	memleak	Memory leak: tmpname

Fixed.

> Also, in my experience, cppcheck does a better job when there are fewer little
> hacks like:
>
> pinentry/gtk+-2/gtksecentry.h:188 syntaxError
> 	Invalid number of character ({) when these macros are defined:
> 'MAKE_EMACS_HAPPY;__cplusplus'

Replaced by 

  #ifdef __cplusplus
  extern "C" {
  #if 0 
  } /* Make Emacs happy.  */
  #endif
  #endif /* __cplusplus */

which is what is used everywhere else.


> So the question is whether these should be automatically reported to
> committers, like build errors and test errors?  Are there any other static

That are the only errors, or did you filter them?


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.