[cfe-commits] [PATCH] Fix for PR7218, and analyzer support for calloc()

Zhongxing Xu xuzhongxing at gmail.com
Fri May 28 23:28:54 PDT 2010


Hi Jordy,

I've applied a minimum of your patch that fixes PR7218. Could you please
make a new patch of the rest of the logic?

A specific question about the part of the patch that I adopted:

+bool RegionStoreManager::canHaveDirectBinding (const MemRegion *R) {
+  // Arrays can't have direct binding -- must bind to elements
+  if (const TypedRegion *TR = dyn_cast<TypedRegion>(R))
+    if (TR->getValueType(getContext())->isArrayType())
+      return false;
+
+  // Symbolic regions are the same, unless they are references
+  if (const SymbolicRegion *SR = dyn_cast<SymbolicRegion>(R))
+    if (!SR->getSymbol()->getType(getContext())->isReferenceType())
+      return false;

I'm not very clear about the semantics of this case. When could a symbolic
region have reference type? Could you please illustrate it a bit, better
with an example.

+
+  return true;
+}

On Sat, May 29, 2010 at 8:11 AM, Jordy Rose <jediknil at belkadan.com> wrote:

>
> Fixes PR7218 "Assigning to buf[0] makes buf[1] valid" by not allowing
> arrays and symbolic regions to have direct bindings, only bindings to
> element 0. (The exception is symbolic regions for references, since they
> don't have elements.)
>
> On top of that, adds support for calloc(), treating its result as a
> malloc-region that needs freeing, whose contents are initialized to 0.
>
> I'm not entirely happy with the replacement of *p with p[0] in
> GRExprEngine, but that seems to be the last place where you can tell the
> difference between a binding to p and a binding to p[0].
>
> This could be split into two patches, of course, though I worked on it all
> simultaneously. The calloc() part requires a way to set default elements
> for regions -- I did it by using the assumption that arrays and symbolic
> regions couldn't get direct bindings, only default ones, but it could also
> be done by adding another method to Store (really RegionStore).
>
> Jordy
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20100529/8f52ee4f/attachment.html>


More information about the cfe-commits mailing list