[PATCH] Adding ASAN support for libc++'s vector

[Kostya Serebryany]

Looks great, ship it!
Few minor comments below.

+++ include/__config    (working copy)
+#ifndef _LIBCPP_HAS_NO_ASAN

Do you prefer double-negative statements?
#ifdef _LIBCPP_HAS_ASAN
might be easier to read, but that's not critical.


+++ test/containers/sequences/vector/asan.pass.cpp      (working copy)
+#ifndef _LIBCPP_HAS_NO_ASAN
+extern "C" void __asan_set_error_exit_code(int);

+++ test/support/asan_testing.h (working copy)
+#ifndef _LIBCPP_HAS_NO_ASAN
+extern "C" int __sanitizer_verify_contiguous_container
+     ( const void *beg, const void *mid, const void *end );

I understand the desire to not incluide <sanitizer/asan_interface.h> in
include/__config,
but why not include it in the test files?


+++ test/containers/sequences/vector/asan.pass.cpp      (working copy)
+#if __cplusplus >= 201103L
+    {
+        typedef int T;
+        typedef std::vector<T, min_allocator<T>> C;
+        const T t[] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
+        C c(std::begin(t), std::end(t));
+        c.reserve(2*c.size());
+        T foo = c[c.size()];    // bad, but not caught by ASAN
+    }
+#endif

Maybe add a comment explaining why ASAN does not catch it
(because asan can't handle arbitrary allocator)?




On Wed, May 7, 2014 at 1:05 AM, Marshall Clow <mclow.lists at gmail.com> wrote:

> Address sanitizer does not currently check for accesses beyond the end of
> a vector, but within the memory block managed by the vector.
>
> For example:
>         vector<int> v;
>         v.reserve(10); // make space for 10 elements, but vector is still
> empty
>         cout << v[1]; // access outside the “valid elements” of the vector.
>
> This patch adds the ability to detect these kinds of errors to libc++ when
> using Address Sanitizer.
> Thanks to Kostya for most of the code here.
>
> — Marshall
>
>
>
>
> _______________________________________________
> 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/20140507/f399f44b/attachment.html>