[cfe-dev] uninitialized variable warning, etc

[रजनीश]

Thanks Daniel,

May be there should note on how a programmer would do the compile
and analysis, So they won't get confused.   I mean do I compile and then
analyze.

anyway I ran the analyze command
on test.c and it only gave one warning. may be ccc is not passing - 
analyze command
properly.

~/clang-test-> cat test.c
#include <stdio.h>
#include <stdlib.h>

int main (void)  {
   int a = 0;
   int  b;

   a = b + a;
   printf ("a = %d", a);

   exit(0);
}

~/clang-test-> ccc --analyze test.c
test.c:9:3: warning: Pass-by-value argument in function call is  
undefined.
   printf ("a = %d", a);
   ^                 ~
1 diagnostic generated.

If I comment out the printf statement then I also only get one  
warning.  So something is wrong.
~/clang-test-> ccc --analyze test.c
test.c:8:3: warning: Value stored to 'a' is never read
   a = b + a;
   ^   ~~~~~
1 diagnostic generated.

P.S.  I would expect -Wall to cover all warning but I guess I am  
asking too much.

On Mar 6, 2009, at 12:21 PM, Daniel Dunbar wrote:

> Hi,
>
> clang does not yet implement the uninitialized values warning outside
> of the static analysis engine.
> --
> ddunbar at lordcrumb:tmp$ cat t4.c
> int f0(void)  {
>  int b;
>  return b;
> }
> ddunbar at lordcrumb:tmp$ ccc --analyze t4.c
> t4.c:3:3: warning: Uninitialized or undefined return value returned  
> to caller.
>  return b;
>  ^
> 1 diagnostic generated.
> --
>
> Feel free to file a bug if you like; however this is the sort of
> warning that the static analyzer is much more suited to emitting. We
> never want to have the gcc behavior where warnings depend on
> optimization level or have warnings emitted by the backend.
>
> On Thu, Mar 5, 2009 at 6:36 PM,  <rdogra at earthlink.net> wrote:
>> libavcodec/dsputil.c:3966:10: warning: use of unary operator that may
>> be intended as compound assignment (-=)
>>    for(i=-len, j=len-1; i<0; i++, j--) {
>>         ^~
>
> Yes; we may well end up disabling this warning by default as it
> appears to be quite noisy on some code bases.
>
> - Daniel