cbd3801acf
In general, if we see an allocation, we associate the immutable memory space with the constructed memory region. This works fine if we see the allocation. However, with symbolic regions it's not great because there we don't know anything about their memory spaces, thus put them into the Unknown space. The unfortunate consequence is that once we learn about some aliasing with this Symbolic Region, we can't change the memory space to the deduced one. In this patch, we open up the memory spaces as a trait, basically allowing associating a better memory space with a memregion that was created with the Unknown memory space. As a side effect, this means that now queriing the memory space of a region depends on the State, but many places in the analyzer, such as the Store, doesn't have (and cannot have) access to the State by design. This means that some uses must solely rely on the memspaces of the region, but any other users should use the getter taking a State. Co-authored-by: Balazs Benics <benicsbalazs@gmail.com>
C language Family Front-end
Welcome to Clang.
This is a compiler front-end for the C family of languages (C, C++ and Objective-C) which is built as part of the LLVM compiler infrastructure project.
Unlike many other compiler frontends, Clang is useful for a number of things beyond just compiling code: we intend for Clang to be host to a number of different source-level tools. One example of this is the Clang Static Analyzer.
If you're interested in more (including how to build Clang) it is best to read the relevant websites. Here are some pointers:
-
Information on Clang: http://clang.llvm.org/
-
Building and using Clang: http://clang.llvm.org/get_started.html
-
Clang Static Analyzer: http://clang-analyzer.llvm.org/
-
Information on the LLVM project: http://llvm.org/
-
If you have questions or comments about Clang, a great place to discuss them is on the Clang forums:
-
If you find a bug in Clang, please file it in the LLVM bug tracker: