--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: libstdc++5: Questionable type usage in mangled names
- From: Stuart Anderson <anderson@netsweng.com>
- Date: Thu, 14 Nov 2002 21:13:37 -0500
- Message-id: <E18CVzG-0000JE-00@localhost>
Package: libstdc++5
Version: 1:3.2.1-0pre6
Severity: normal
Tags: upstream
Underlying types are used when creating the mangled name of symbols in C++. In
libstdc++, many symbols contains the type mbstate_t. As encoded in the mangled
name, the underlying type, __mbstate_t is used. When unmangled, this results
in a different source name than what was used in the source.
Here is an example:
libstdc++ contains the symbol _ZNKSt7codecvtIcc11__mbstate_tE11do_encodingEv.
c++filt de-mangles this as
std::codecvt<char, char, __mbstate_t>::do_encoding() const,
which is not the same thing as in the ISO C++ specification, which would be
std::codecvt<char, char, mbstate_t>::do_encoding() const
(ref ISO C++ 22.2.1.5). The difference is __mbstate_t vs mbstate_t.
It seem that an unmangling operation should produce the original source symbol.
This seems like it may be an ABI issue as the C++ headers produce different
mangled symbol if headers other than GNU libc headers are used. We ran into
this when testing the LSB development environment in conjunction with C++. The
LSB description of mbstate_t is a typedef of an anonymous structure, and
doesn't have the intermediate __mbstate_t as the glibc headers do. Since
__mbstate_t doesn't seem to be present in the source standards, we didn't want
to include it in the LSB descriptions.
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux bego 2.4.18 #25 Tue Aug 6 14:04:58 EDT 2002 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages libstdc++5 depends on:
ii gcc-3.2-base 1:3.2.1-0pre6 The GNU Compiler Collection (base
ii libc6 2.3.1-3 GNU C Library: Shared libraries an
ii libgcc1 1:3.2.1-0pre6 GCC support library.
-- no debconf information
--- End Message ---