3 ms·
> asan/ubsan are great for finding language-level undefined behavior. But apart from some functions like memcpy that asan is hooking, they cannot find library-l
by jcelerier 4y ago
> asan/ubsan are great for finding language-level undefined behavior. But apart from some functions like memcpy that asan is hooking, they cannot find library-level undefined behavior such as the pop_back() on the empty vector. (That's an inline function inside a template, there's no way asan could hook this!)
no, libstdc++ is at least partly instrumented with explicit asan support : https://gcc.gnu.org/legacy-ml/libstdc++/2017-07/msg00014.html https://gcc.gnu.org/legacy-ml/libstdc++/2017-07/msg00014.htm... so fsanitize should be able to catch it (and after checking, definitely does: https://gcc.godbolt.org/z/rjadKvPTs https://gcc.godbolt.org/z/rjadKvPTs)
- ynik 4y agoThat's a special case due to an empty vector using nullptr, and thus causing language-level UB when doing pointer arithmetic with a nullptr. If you add an element to the vector and then remove it twice, asan will no longer find any problem: https://gcc.godbolt.org/z/MbPhWv8vn https://gcc.godbolt.org/z/MbPhWv8vn
- jcelerier 4y agoahhh just double checked and it is hidden behind a macro for libstdc++... see: https://gcc.godbolt.org/z/e7Wj163PM https://gcc.godbolt.org/z/e7Wj163PM
- ynik 4y agoInteresting, I wasn't aware of that one. I think `-D_GLIBCXX_ASSERTIONS` is more appropriate for catching this bug, but `-D_GLIBCXX_SANITIZE_VECTOR` seems useful for cases like this: https://gcc.godbolt.org/z/EjrdoTYPs https://gcc.godbolt.org/z/EjrdoTYPs This is really the main problem with "safe modern C++": to get actual safety you need dozens of weird implementation-specific opt-ins and there's no good way to learn that these even exist.