Mass filing of clang warnings

Hans-Christoph Steiner hans at guardianproject.info
Mon Mar 16 18:56:43 CET 2015



Werner Koch:
> On Fri, 13 Mar 2015 15:48, hans at guardianproject.info said:
> 
>> That's the kind of stuff that I'm talking about.  The key point I'm talking
>> about is not about whether the code that triggers the warning is correct or
>> not.  It is about making it correct AND simple enough for cppcheck to
>> understand.  That last point is what I'm discussing.
> 
> I know.  However it depends on the case.  A change like 
> 
>   -  char buffer[BUFFER_SIZE];
>   +  char buffer[BUFFER_SIZE] = ""; // make cppcheck happy
> 
> this wrong.  BUFFER is not expected to be initialized.  A flow analysis
> may later come and warn about a useless initialization of BUFFER.
> 
> Agreed, I do that sometimes for scalars or pointers which are for
> example controlled by a flag variable.  I really hate to do that but I
> need to shut up gcc in some cases.  The problem behind such dummy
> initialization is that improved compilers won't be able to detect a
> really non-initialized variable or complain about initialized but not
> used variable.  It is always a tradeoff.  
> 
> Also recall that there are more compilers than gcc and Clang.  Some even
> provided better warnings many years ago.
> 
> If there would only be an annotation format which keeps the actual
> source readable (ie. in a separate automagically maintained file).

At this point, I'm not talking about compilers.  I'm talking about cppcheck,
which actually found issues that you confirmed and fixed.

That specific example is not particularly worth discussion IMHO.  I am sure
there is a way to make cppcheck happy that makes sense in the code.  That way,
GnuPG can gain the real benefits of automatic runs of cppcheck.

Right now, it does not seem worthwhile to try to figure the correct way
because you have only expressed opposition to the idea of adjusting the code
to make cppcheck work better.

.hc

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81



More information about the Gnupg-devel mailing list