[libcxx-commits] [libcxx] [libc++] Honor __SANITIZER_DISABLE_CONTAINER_OVERFLOW__ in libc++ (PR #168955)

[Paddy McDonald via libcxx-commits]

================
@@ -0,0 +1,75 @@
+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+// XFAIL: FROZEN-CXX03-HEADERS-FIXME
+// REQUIRES: asan
+
+// Check that libc++ honors when __SANITIZER_DISABLE_CONTAINER_OVERFLOW__ is set
+// and disables the container overflow checks.
+
+// ADDITIONAL_COMPILE_FLAGS: -D__SANITIZER_DISABLE_CONTAINER_OVERFLOW__
+
+#include <deque>
+#include <string>
+#include <vector>
+
+// This check is somewhat weak because it would pass if we renamed the libc++-internal
+// macro and forgot to update this test. But it doesn't hurt to check it in addition to
+// the tests below.
+#if _LIBCPP_ENABLE_ASAN_CONTAINER_CHECKS
+#  error "Container overflow checks should be disabled in libc++"
+#endif
+
+void vector() {
+  std::vector<int> v;
+  v.reserve(100);
+  int* data = v.data();
+
+  // This is illegal with respect to std::vector, but legal from the core language perspective since
+  // we do own that allocated memory and `int` is an implicit lifetime type. If container overflow
+  // checks are enabled, this would fail.
+  data[4] = 42;
+}
+
+// For std::string, we must use a custom char_traits class to reliably test this behavior. Since
----------------
padriff wrote:

I like the approach.  I agree that it is very unlikely for someone to ship a sanitized  libcxx.  If they are building that way it is more than likely to allow them to have a fully sanitized stack for testing purposes

https://github.com/llvm/llvm-project/pull/168955