[cfe-commits] r86252 - in /cfe/trunk: include/clang/Analysis/PathSensitive/Checker.h lib/Analysis/CMakeLists.txt lib/Analysis/GRExprEngineInternalChecks.cpp lib/Analysis/GRExprEngineInternalChecks.h lib/Analysis/ReturnPointerRangeChecker.cpp test

[Zhongxing Xu]

2009/11/7 Ted Kremenek <kremenek at apple.com>:
> On Nov 6, 2009, at 2:02 PM, Cédric Venet wrote:
>
>>
>>>> +int a[10];
>>>> +
>>>> +int *f0() {
>>>> +  int *p = a+10;
>>>> +  return p; // expected-warning{{Return of Pointer Value Outside of
>>>> Expected Range}}
>>>> +}
>>>>
>>>>
>>
>> This could leads to false positive in case like:
>>
>> struct Array10 {
>>     int a[10];
>>     typedef int* iterator;
>>     iterator begin() { return a; }
>>     iterator end() { return a+10; }
>> }
>>
>> since while it is not allowed to dereference the p, it is legal to
>> have
>> a pointeur one element after the end.
>> On the other hand, only triggering the warning if the pointer is two
>> elements (or more) after the end would limit the usefulness of the
>> analysis.
>
> This is a reasonable concern.  I'd prefer a false negative here
> instead of a commonly occurring false positive.  The strategy I see:
>
> (1) If the pointer returned points before the buffer, ERROR
>
> (2) If the pointer returned points to >= 2 bytes beyond the buffer,
> ERROR
>
> (3) If the pointer returned points to 1 byte beyond the buffer, only
> ERROR when we have a higher confidence that this is valid
>
> Clearly (3) is going to be black art, but that seems reasonable.  We
> start with not ERRORing in this case, and gradually expand.

This is reasonable.

> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>