s-barannikov wrote: > The -fexec-charset option used for the c++ library may not be the same as in > the user source. The design point is to have one typeinfo object per type. In > a simple example we can have two source files defining two types compiled > with two different -fexec-charset options. This will result in typeinfo > objects being defined in three different places: > > 1. the basic types in standard c++ library > 2. type T1 defined in the first source file > 3. type T2 defined in the second source file > > If these are all in different code pages, users won't be able to know what > code page is being returned by name().
Linking objects compiled with different -fexec-charset option would be a programmer mistake because the objects are not ABI compatible (in some sense). You can't safely pass strings across object boundaries if the objects are compiled with different -fexec-charset options. For example, if your program compiled with -fexec-charset=ascii tries to examine an ebcdic-encoded string returned by type_info::name() (e.g., tries to demangle it), it will fail. If you compile libc++-/abi with -fexec-charset=ascii, you will get rubbish in "std::terminate called after throwing an exception of type std::bad_alloc", because the "std::bad_alloc" part will be demangled using the wrong (ASCII) decoder. These are the same problems you get when passing any strings hardcoded in any library to another library compiled with different -fexec-charset option. I still don't see how type_info::name() is different. https://github.com/llvm/llvm-project/pull/138895 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
