[cfe-dev] How to fix this Clang report bug?

[Jordan Rose]

Yes; unfortunately the analyzer only processes one translation unit at a time (main source file + all included headers), just like the compiler. Support for cross-translation unit analysis is way down the line, since it's a huge restructuring of how we do things.

I think the only thing that's more standard about an enum is that it allows you to do fully-covered switch checks, if that's ever useful. It also means you can't take the address of the constants, which usually isn't important. One thing that the constants do allow is that if you ever depend on the value, you could change the value in the .c file without recompiling everything else. But you probably don't care about the value, other than possibly being non-positive.

Best,
Jordan


On Aug 7, 2013, at 1:34 , 凌欢 <linghuan713 at 126.com> wrote:

> hi, Jordan:
> Our  Jce_c.h file has the following define:
> extern const Int32 JCE_SUCCESS        ;      //成功
> extern const Int32 JCE_ATTR_NOT_FOUND ;      //查找不到相关属性
> extern const Int32 JCE_ENCODE_ERROR   ;      //编码错误
> extern const Int32 JCE_DECODE_ERROR   ;      //解码错误
> extern const Int32 JCE_RUNTIME_ERROR  ;      //其他运行时错误
> extern const Int32 JCE_MALLOC_ERROR   ;      //内存申请失败错误
> While the Jce_c.c file has the following define:
> const Int32 JCE_SUCCESS        =  0;	  //成功
> const Int32 JCE_ATTR_NOT_FOUND = -1;	  //查找不到相关属性
> const Int32 JCE_ENCODE_ERROR   = -2;	  //编码错误
> const Int32 JCE_DECODE_ERROR   = -3;	  //解码错误
> const Int32 JCE_RUNTIME_ERROR  = -4;	  //其他运行时错误
> const Int32 JCE_MALLOC_ERROR   = -5;	  //内存申请失败错误
> So why the scan-build can't read the value from .c file ? Is it the weak point for the Clang?
> In theory , put the the constants in an enum is more proper/stander codeing  ?
> Thanks Jordan.
>  
>  BRs
> Howard Ling
> *****************************************************
>  
> E-mail:    linghuan713 at 126.com
>  
> *****************************************************
> At 2013-08-06 23:32:11,"Jordan Rose" <jordan_rose at apple.com> wrote:
> Right, then. You've never actually told the analyzer that JCE_SUCCESS and JCE_MALLOC_ERROR are distinct constants, so it's not going to be able to do a good job here. You can either make the definitions of the constants visible, or put them in an enum (same basic idea). (In theory you could assert that they are different, but the analyzer doesn't track relationships between independent symbolic values. Besides, you'd have to assert that in every function.)
> 
> Sorry for the inconvenience,
> Jordan
> 
> 
> On Aug 6, 2013, at 2:25 , 凌欢 <linghuan713 at 126.com> wrote:
> 
>> 
>> It is defined extern const Int 32.
>> 
>>  BRs
>> Howard Ling
>> *****************************************************
>>  
>> E-mail:    linghuan713 at 126.com
>>  
>> *****************************************************
>> 在 2013-08-03 09:12:56，"Jordan Rose" <jordan_rose at apple.com> 写道：
>> 
>> On Aug 2, 2013, at 4:08 , 凌欢 <linghuan713 at 126.com> wrote:
>> 
>>> HI, all :
>>> Our developers says that if set NULL to the pointer ,it can be used after released , is it right ? Following the the code which is
>>> reported by scan-build and the type is used after release , can anyone tell me how to fix the bug ?
>>> Or is it the false positive ?  please see the attathed .c file for the detail which is start line 896, end line 942.
>>>  Thanks all .
>> 
>> The false positive comes from this line:
>> 
>>     if(JCE_SUCCESS != ret) { return NULL; }
>> 
>> For some reason, we think that ret == JCE_SUCCESS when the allocation fails, but the path clearly shows JCE_MALLOC_ERROR being returned.  So now the only question is, why does the analyzer think JCE_MALLOC_ERROR and JCE_SUCCESS can be the same thing? Are they defined as "extern Int32" instead of constants?
>> 
>> Jordan
>> 
>> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130808/72ced93b/attachment.html>