[libcxx-dev] Is the implementation of two-argument __non_unique_arm_rtti_bit_impl; ; __is_type_name_unique correct?

Stephan Bergmann via libcxx-dev libcxx-dev at lists.llvm.org
Wed Dec 16 06:07:21 PST 2020

About the code originally introduced into libcxx/include/typeinfo as

>     bool operator==(const type_info& __arg) const _NOEXCEPT
>         {return __type_name == __arg.__type_name;}
> #else
>         {if (__type_name == __arg.__type_name) return true;
>          if (!((__type_name & __arg.__type_name) & _LIBCPP_NONUNIQUE_RTTI_BIT))
>            return false;
>          return __compare_nonunique_names(__arg) == 0;}
> #endif

"ARM64: compare RTTI names as strings", and then factored out to

>     static bool __is_type_name_unique(__type_name_t __lhs, __type_name_t __rhs) _NOEXCEPT {
>       return !((__lhs & __rhs) & __non_unique_rtti_bit::value);
>     }

"Rework std::type_info definition to support systems without fully 
merged type info names":

I wonder if it is correct to compute `__lhs & __rhs` rather than `__lhs 
| __rhs`?  The documentation of NonUniqueARMRTTIBit (also in 
libcxx/include/typeinfo) states that "we check whether BOTH type_infos 
are guaranteed unique, and if so, we simply compare the addresses of 
their type names instead of doing a deep string comparison, which is 
faster.  If at least one of the type_infos can't guarantee uniqueness, 
we have no choice but to fall back to a deep string comparison."

So my understanding is that __is_type_name_unique should return false 
(and comparison fall back to deep string comparison) when at least one 
of __lhs and __rhs has the __non_unique_rtti_bit set, not only when both 
have it set.

More information about the libcxx-dev mailing list