Xcode 7 allows address sanitizer to be used to find memory issues in C/C++.
https://github.com/google/sanitizers/wiki/AddressSanitizer
Turning on address sanitizer passes the compile and linker flag -fsanitize=address and also defines _LIBCPP_HAS_NO_ASAN.
When building my library from the command line and running tests on a sanitized build without defining _LIBCPP_HAS_NO_ASAN I see non-repeatable address-sanitizer-reported memory access issues. Defining _LIBCPP_HAS_NO_ASAN, as Xcode does, gets rid of the sanitizer issues but I'm curious as to why it needs doing.
Why do I need to define _LIBCPP_HAS_NO_ASAN with AppleClang7 to avoid getting memory access issues in libcxx?
From discussion with Sean McBride (who is not on StackOverflow) there are known issues with spurious memory-out-of-bounds errors when mixing instrumented and non-instrumented code:
From Anna Zaks on http://lists.apple.com/archives/xcode-users/2016/Jan/msg00077.html:
"Generally, one does not need to rebuild any code that is being linked into sanitized code."
"However, there is one corner case in C++ container overflow checking, where this might not always hold. Specifically, if libc++ containers cross from instrumented (rebuilt with ASan) to non-instrumented code, Address Sanitizer might report container overflow false positives. (Imagine two libraries, both using the same std::vector, only one of them is instrumented. Push_back from the non-instrumented module will not mark the memory for the newly added element as valid. Accessing the element from the instrumented code, would trigger a false positive report.)"
I hope this question helps someone else as this problem has consumed a considerable amount of my time. Asan is great but this info was hard to find.