[cfe-dev] Fwd: Fwd: [analyzer] false positive in loop?

[Francisco Chiotta via cfe-dev]

Hi Artem,

Thank you for your help. The definition of the list is available in the
current translation unit, but I was able to turn off the warning changing
the variable list to be a pointer, and using concrete values for the
condition of the iteration instead of "*i < list.getSize**()*". As I
understand, loops, by default, unroll a fixed amount of times when the
condition is symbolic, defining like a symbolic offset. Do we keep any
reasoning about this symbolic offset? if the iteration unroll say 4 times,
and the condition is *"int i = 0; i<list.getSize()**; i++"*, maybe I will
expected the variable i to have the concrete values 0, 1, 2  and 3 at a
time. Is this thought wrong?

When the list is passed on by value, even when using concrete values for
the condition, the analyzer reports the bug. Why could it be happening?
Maybe because of the same thing happening in the symbolic iteration of the
copy constructor.

The list definition is pretty simple:

class IntegerList {

private:

  int* ptr;

  int size;

  int maxCapacity;

public:

  IntegerList(int maxCapacity){

    ptr = new int[maxCapacity];

    this->maxCapacity = maxCapacity;

    this->size = 0;

  }



  ~IntegerList(){free(ptr);}



  IntegerList(const IntegerList& IL){

    ptr = new int[IL.size];

    for (int i = 0 ; i < IL.size; i++){

      ptr[i] = IL.at(i);

    }

    size = IL.size;

    maxCapacity = IL.maxCapacity;

  }



  int getSize() const {return size;}



  int at(int pos) const {return (pos>=0 && pos<size)?ptr[pos]:-1;}



  void add(int elem){

    if (size < maxCapacity){

      ptr[size]=elem;

      size++;

    }

  }

};

2015-12-03 7:09 GMT-03:00 Artem Dergachev via cfe-dev <
cfe-dev at lists.llvm.org>:

> I think this case is of an actual false positive:
>
> (1) Our constraint solver (RangeConstraintManager) is very simple and
> doesn't yet handle constraints like "x is odd" properly. Not quite sure, in
> fact maybe at least adding a "== 0" range on the SymIntExpr "x % 2" should
> have helped, why don't we do at least that? I'd have had a look.
>
> (2) If IntegerList::at() is not inlined properly (doesn't have its body
> available for analysis), then the analyzer would not realize that the
> symbol checked in hasEvenNumbers() is the same symbol that is checked in
> walkthrough(); at() may return a different value, and blindly assuming this
> value to be the same (eg. assuming all unknown functions to be pure) would
> make things a lot worse. This is a more complicated work of supporting
> (evalCall'ing or BodyFarm'ing) STL containers, assuming IntegerList is a
> typedef for some std::list<int>, or if you use custom containers, then you
> need to have a checker to support them, or inter-unit analysis may be of
> use if the body of container methods is in fact available, just in another
> translation unit.
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151213/1b3da562/attachment.html>