Anthony Feick - Re: wide character issues with gcc 3.2 (original) (raw)

This is the mail archive of the libstdc++@gcc.gnu.orgmailing list for the libstdc++ project.

• From: "Anthony Feick"
• To: bkoz at redhat dot com
• Cc: libstdc++ at gcc dot gnu dot org
• Date: Thu, 22 Aug 2002 16:13:02 -0500
• Subject: Re: wide character issues with gcc 3.2
• Bcc:

From: Benjamin Kosnik bkoz@redhat.com To: "Anthony Feick" afeick@hotmail.com CC: libstdc++@gcc.gnu.org Subject: Re: wide character issues with gcc 3.2 Date: Tue, 20 Aug 2002 13:06:18 -0700

Gcc 3.2 on linux compiles and links our app, but -fshort-wchar doesn't seem to be working completely. The compiler directive 'L' converts character strings properly, and wchar_t is the right size. The problem is that "basic_string" still thinks everything is 4-bytes.

...because the library has been compiled without this flag, for starters. You'd have to pass it in with CXXFLAGS, or configure with --enable-cxx-flags="-fshort-wchar"

I did this, but now I get a segfault in stl_alloc.h :

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 3072)]
std:🧵:_Rep::_S_create(unsigned, std::allocator const&) (__capacity=7, __alloc=@0xbffff810)
at /home/shared/software/gcc-3.2-obj/i686-pc-linux-gnu/libstdc++-v3/include/bits/stl_alloc.h:397
397 *__my_free_list = __result -> _M_free_list_link;
(gdb) bt
#0 std:🧵:_Rep::_S_create(unsigned, std::allocator const&) (__capacity=7, __alloc=@0xbffff810)
at /home/shared/software/gcc-3.2-obj/i686-pc-linux-gnu/libstdc++-v3/include/bits/stl_alloc.h:397
#1 0x400e2d25 in char* std:🧵:_S_construct<char const*>(char const*, char const*, std::allocator const&, std::forward
_iterator_tag) (__beg=0x88db524 "muadclp", __end=0x88db52b "", __a=@0x40129728)
at /home/shared/software/gcc-3.2-obj/i686-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:150
#2 0x400df014 in basic_string (this=0x370036, __s=0x88db52b "", __a=@0x88db524)
at /home/shared/software/gcc-3.2-obj/i686-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:732
#3 0x0840391f in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535)
at ../../creatortech/portlib/PhotoshopTags.h:55
#4 0x084039b0 in _GLOBAL__I__ZN7PortLib15CPlatformBitmapC2Ev () at ../../creatortech/portlib/Path.h:261
#5 0x0871f2d5 in __do_global_ctors_aux ()
#6 0x0804e906 in _init ()
#7 0x4016e26a in __libc_start_main () from /lib/libc.so.6

Unfortunately, I don't have a 'simple' test case for this.

$ gcc -v
Reading specs from /home/shared/local/lib/gcc-lib/i686-pc-linux-gnu/3.2/specs
Configured with: ../gcc-3.2/configure --prefix=/home/shared/local --enable-shared --enable-threads=posix --enable-__cxa_atexit --e
nable-cxx-flags=-fshort-wchar
Thread model: posix
gcc version 3.2

There are additional issues with wide character support on BSD's, as some of the underlying "C" library bits for C99 support in wchar.h, wctype.h, are not implemented, but try to get this working on linux first would be my suggestion.

-benjamin

Yes, I See FreeBSD has some distance to go before supporting wide character string functions:
http://www.freebsd.org/projects/c99/

That's too bad. We had been using a hack in our code to get systems without wide char string functions to work (convert the unicode to ascii then call the ascii string functions). But it doesn't look like that will be possible on FreeBSD without hacking libstdc++ itself.

_________________________________________________________________
Join the world�s largest e-mail service with MSN Hotmail. http://www.hotmail.com

• Follow-Ups:
  • Re: wide character issues with gcc 3.2
    * From: Benjamin Kosnik