[LLVMbugs] [Bug 8938] New: wint_t definition clashes with GCC compiled c++ standard library

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=8938

           Summary: wint_t definition clashes with GCC compiled c++
                    standard library
           Product: clang
           Version: unspecified
          Platform: Macintosh
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Headers
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: admin at thefireflyproject.us
                CC: llvmbugs at cs.uiuc.edu


The definition of wint_t
(http://llvm.org/svn/llvm-project/cfe/trunk/lib/Basic/TargetInfo.cpp line 45,
`WIntType = SignedInt;') conflicts with the definition of wint_t provided by
GCC (GCC defines wint_t as an unsigned int).

This (subtly) breaks clang on Linux, unless one uses a non-GCC compiled GNU
stdlib (I can't remember when I last tried compiling GNU stdlib with clang, but
I didn't have success. libc++ uses a Mac OSX centric build set up and I've only
had moderate success getting it to function on Linux). Debian and Ubuntu's
clang packages depend on GCC compiled GNU stdlib packages; there is not a
clang-compiled GNU stdlib package that I know of. I believe other distros
(RPM-based, etc) also distribute clang with GCC-built GNU stdlib.

Subsequently, this leads clang to fail to pass Boost C++ regressions for a
number of Boost libraries: string_algo, asio, graph, iostreams, math, regex,
serialization, spirit, units and uuid. The point of failure is std::wstreambuf;
the pbackfail and overflow methods take a parameter of int_type, which is
wint_t in the case of the std::wstreambuf typedef. GCC compiles the shared
library with wint_t typedef'd to an unsigned int, thus leading to a mismatch in
the function signature of pbackfail and overflows declaration (in the headers,
compiled by clang) and the definition (in the shared library, compiled by GCC).

This definition was introduced on Oct 21st, 2009 - git-svn-id:
http://llvm.org/svn/llvm-project/cfe/trunk@84740
91177308-0d34-0410-b5e6-96231b3b80d8. 

This problem doesn't occur on darwin (our clang-linux tester has been down for
awhile, so I thought this was just a problem for me for a period of time). I'm
assuming that's because either 0.) Apple ships a modified version of gcc with
Xcode that defines wint_t as an int, and Apple's shipped GNU stdlib package is
compiled with said modified version of gcc 1.) Apple has been building GNU
stdlib with clang since this change was introduced 2.) Apple has been using
libc++ since this change was introduced.

This is not a problem that I have been able to solve on the Boost end of things
with a workaround (I've fixed other stream-related stdlib issues with clang +
linux + gnu stdlib + boost by hacking together an implementation of the broken
component and having Boost use it if in a clang linux environment, but I'd
pretty much have to reimplement the entire stream library for this one). I
suspect changing the definition of wint_t in clang for all platforms will break
some existing code/interoperability with existing binaries. OTOH, this seems to
be a pretty fundamental inconsistency between clang and GCC-4.2 throught
GCC-4.4 (at least on Debian and from GNU's VCS trunk, GCC-4.5/libstdc++-4.5
replaces previously working C++03 and C++98 parts of the GNU standard library
with C++0x code that only GCC can compile, so I didn't bother checking if
GCC-4.5 defines wint_t differently).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.