[libcxx-dev] Non-merged type info name comparison

[Louis Dionne via libcxx-dev]

> On Sep 23, 2019, at 15:15, Shoaib Meenai via libcxx-dev <libcxx-dev at lists.llvm.org> wrote:
> 
> Ah, sorry – my apologies.
>  
> From: Marshall Clow <mclow.lists at gmail.com>
> Date: Monday, September 23, 2019 at 12:14 PM
> To: Shoaib Meenai <smeenai at fb.com>
> Cc: "libcxx-dev at lists.llvm.org" <libcxx-dev at lists.llvm.org>
> Subject: Re: [libcxx-dev] Non-merged type info name comparison
>  
> On Mon, Sep 23, 2019 at 12:02 PM Shoaib Meenai via libcxx-dev <libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>> wrote:
> In https://reviews.llvm.org/rL361913 <https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_rL361913&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=zXNo5HfpEBs2AeK5MYbybBHSXRWS2rfFR2LYPo1zuhA&s=5In-WOhspL-mxLcgsafyIl0_G_S9IkKnfaj3lVT6y44&e=>, libc++ gained the option to make type info comparisons use a strcmp on the type info name, which is useful for when we can’t guarantee RTTI uniqueness. I believe libstdc++ also defaults to strcmp comparisons. However, libstdc++ doesn’t perform the string comparison when the type info name begins with the * character [1], which is the case for e.g. types defined in anonymous namespaces. Should libc++’s implementation be changed to match, at least when targeting Linux?
Actually, in what cases can we guarantee that RTTI has been fully duplicated? For example, I don't think anything prevents users from using a shared library that redefines the RTTI for a type, no?

I've had a couple of complaints of people saying we should do the string comparison -- I wonder whether we might have put performance above correctness in this case. My reasoning is that if we don't have a valid use case under which RTTI is guaranteed to be unique, we should do the string comparison. And if we do have such a use case, we should evaluate how prominent it is to determine whether we do the slow-but-correct approach by default, or the fast-but-sometimes-incorrect approach by default.

Louis

>  
> [1] https://github.com/gcc-mirror/gcc/blo <https://github.com/gcc-mirror/gcc/blo> (rest of link elided)
>  
>  
> Please don't post links/snippets of GPL code here; we can't look at them for licensing reasons.
>  
> -- Marshall
>  
> _______________________________________________
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190925/4c383e82/attachment.html>