Giant loop back as this was extremely confusing to me and I just got around to investigating.

On Jun 2, 2025, at 4:23 PM, Frederick Virchanza Gotham via Std-Proposals <std-proposals@lists.isocpp.org> wrote:


My code doesn't cause address sanitizer to throw up an alarm. If you
can beat address sanitizer then you can beat anything. Here's how I
build my programs on Linux to debug them:

   set(ENV{ASAN_OPTIONS} "detect_invalid_pointer_pairs=2")
   set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -ggdb3
-pedantic -Wall -Wextra -rdynamic -funwind-tables
-fno-omit-frame-pointer -fno-common -pthread
-fsanitize=address,leak,undefined,pointer-compare,pointer-subtract,float-divide-by-zero,float-cast-overflow
-fsanitize-address-use-after-scope -fcf-protection=full
-fstack-protector-all -fstack-clash-protection -fvtv-debug
-fvtv-counts -finstrument-functions -D_GLIBC_DEBUG
-D_GLIBC_DEBUG_PEDANTIC -D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC")

Not many a bug survives all those options. However my code for
GetMostDerivedObject and GetTypeInfo compiles and runs just fine.

So ignoring whether it “works” or not, you should know that this is UB, and ubsan (-fsanitize=undefined) tries to
report all UB, even if the behavior may be sensible on actual hardware. That’s why I was surprised when you
said it ran cleanly.

Anyway, it looks like it’s a regression in clang: https://godbolt.org/z/dbW6KWKE8

Both typeid and dynamic_cast report an error in 20, but are silent in trunk :(

Filed https://github.com/llvm/llvm-project/issues/143065

—Oliver