automated cppcheck for gnupg

Werner Koch wk at
Tue Apr 15 22:06:15 CEST 2014

On Tue, 15 Apr 2014 21:05, hans at 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


> 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 /* __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?



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

More information about the Gnupg-devel mailing list