[integer] Solaris integer_traits.hpp #error and general Solaris wchar_t issues
The crc library is failing regression tests on Solaris + gcc 3.3.4 (http://tinyurl.com/6qq3y) because of the #error statement on line 112 of integer_traits.hpp (see below). If one includes <wchar.h> before <boost/integer.hpp>, all is well, but if not an error is triggered. Solaris + gcc seems to be a bit of an oddball platform w/r/t wchar_t. It is natively supported and there is a <wchar.h> header, but enough of the C99 wide-character IO routines are missing that gcc does not provide <cwchar>, std::wstring or other related wide features on this platform. The config library sets BOOST_NO_CWCHAR but in integer_traits.hpp I see: 24 #if !defined(BOOST_NO_INTRINSIC_WCHAR_T) && !defined(BOOST_NO_CWCHAR) 25 #include <wchar.h> 26 #endif There is a <wchar.h> but no <cwchar>. Perhaps there ought to be a config macro BOOST_NO_WCHAR_H that could be used instead of BOOST_NO_CWCHAR in this case, or perhaps just the second part of the #if should be dropped. Here's the section of integer_traits.hpp that is generating the error when <wchar.h> is not first included: 85 #ifndef BOOST_NO_INTRINSIC_WCHAR_T 86 template<> 87 class integer_traits<wchar_t> 88 : public std::numeric_limits<wchar_t>, 89 #if defined(WCHAR_MIN) && defined(WCHAR_MAX) 90 public detail::integer_traits_base<wchar_t, WCHAR_MIN, WCHAR_MAX> 91 #elif defined(__BORLANDC__) || defined(__CYGWIN__) || defined(__MINGW32_ _) || (defined(__BEOS__) && defined(__GNUC__)) 92 // No WCHAR_MIN and WCHAR_MAX, whar_t is short and unsigned: 93 public detail::integer_traits_base<wchar_t, 0, 0xffff> 94 #elif (defined(__sgi) && (!defined(__SGI_STL_PORT) || __SGI_STL_PORT < 0 x400))\ 95 || (defined __APPLE__)\ 96 || (defined(__OpenBSD__) && defined(__GNUC__))\ 97 || (defined(__NetBSD__) && defined(__GNUC__))\ 98 || (defined(__FreeBSD__) && defined(__GNUC__))\ 99 || (defined(__hpux) && defined(__GNUC__) && (__GNUC__ == 3) && !defi ned(__SGI_STL_PORT)) 100 // No WCHAR_MIN and WCHAR_MAX, wchar_t has the same range as int. 101 // - SGI MIPSpro with native library 102 // - gcc 3.x on HP-UX 103 // - Mac OS X with native library 104 // - gcc on FreeBSD, OpenBSD and NetBSD 105 public detail::integer_traits_base<wchar_t, INT_MIN, INT_MAX> 106 #elif defined(__hpux) && defined(__GNUC__) && (__GNUC__ == 2) && !define d(__SGI_STL_PORT) 107 // No WCHAR_MIN and WCHAR_MAX, wchar_t has the same range as unsigne d int. 108 // - gcc 2.95.x on HP-UX 109 // (also, std::numeric_limits<wchar_t> appears to return the wrong v alues). 110 public detail::integer_traits_base<wchar_t, 0, UINT_MAX> 111 #else 112 #error No WCHAR_MIN and WCHAR_MAX present, please adjust integer_traits< > for your compiler. 113 #endif 114 { }; 115 #endif // BOOST_NO_INTRINSIC_WCHAR_T -- Caleb Epstein caleb dot epstein at gmail dot com
The crc library is failing regression tests on Solaris + gcc 3.3.4 (http://tinyurl.com/6qq3y) because of the #error statement on line 112 of integer_traits.hpp (see below). If one includes <wchar.h> before <boost/integer.hpp>, all is well, but if not an error is triggered.
I've added a patch to work around it: can you test current mainline cvs to verify that it does indeed fix this for Solaris? Thanks, John.
On Fri, 17 Dec 2004 11:57:32 -0000, John Maddock <john@johnmaddock.co.uk> wrote:
I've added a patch to work around it: can you test current mainline cvs to verify that it does indeed fix this for Solaris?
This indeed fixes the problem for gcc-on-Solaris. Would it be better to test for _GLIBCPP_HAVE_WCHAR_H instead of sun/__sun though? -- Caleb Epstein caleb dot epstein at gmail dot com
Would it be better to test for _GLIBCPP_HAVE_WCHAR_H instead of sun/__sun though?
Or _GLIBCXX_HAVE_WCHAR_H ;-) Or maybe all three: do you know if this is an issue for sun's compiler as well? I'm assuming that wchar.h is provided by the platform rather than by gcc? Thanks, John.
On Tue, 21 Dec 2004 10:49:56 -0000, John Maddock <john@johnmaddock.co.uk> wrote:
Would it be better to test for _GLIBCPP_HAVE_WCHAR_H instead of sun/__sun though?
Or _GLIBCXX_HAVE_WCHAR_H ;-)
Or maybe all three: do you know if this is an issue for sun's compiler as well? I'm assuming that wchar.h is provided by the platform rather than by gcc?
Sun's compiler (at least the version I have) is a whole 'nother set of problems. It fails probably 90% of the tests in the regression suite, largely due to its marginal template support. The test in question (crc) actually causes an ICE with Sun C++ (http://tinyurl.com/52xsu) <wchar.h> is a system header available in /usr/include so it is usable with either compiler. The Sun compiler does provide a <cwchar> header, but gcc does not provide it (nor std::wstring nor any wide stream support) due to the omission of some C99 standard library functions (cf. http://gcc.gnu.org/ml/gcc-help/2003-12/msg00014.html). I would expect that a future release of gcc may fix this issue, since the missing functions are apparently not needed by libstdc++ for its wide support. The platform-specific test for sun/__sun will work for any compiler on this platform, but if there is perhaps some *other* oddball platform out there for which gcc doesn't provide full wide support, then the _GLIBC**_HAVE_WCHAR_H test would catch those as well. -- Caleb Epstein caleb dot epstein at gmail dot com
On Tue, 21 Dec 2004 10:19:40 -0500, Caleb Epstein <caleb.epstein@gmail.com> wrote:
I would expect that a future release of gcc may fix this issue, since the missing functions are apparently not needed by libstdc++ for its wide support.
Looks like this is indeed fixed in gcc 3.4.3, so I'll try using that to run my regression tests on Solaris from this point. -- Caleb Epstein caleb dot epstein at gmail dot com
participants (2)
-
Caleb Epstein -
John Maddock