Help with cross-platform wchar_t to utf8 conversion

Joshua Root jmr at macports.org
Mon Feb 2 22:34:43 PST 2009


David Bruce wrote:
> Hi,
> 
> I'm the upstream maintainer for Tux Math and Tux Typing.  I just
> contributed a current portfile for tuxmath, and would like to add
> tuxtype as well.  The tuxtype port is almost ready to go, but a
> significan part of the game doesn't work because the existing code to
> convert a wchar_t string to utf8 doesn't work as built by macports.
> 
> Tuxtype is a C program that uses SDL, without any Mac-specific
> libraries.  The existing conversion uses iconv, with a check to take
> into account Microsoft's two-byte wchar_t.  I had assumed the Mac
> would work just like Linux in this regard, but so far it hasn't.
> 
> The relevant OS-specific part works like this:
> 
>  //Microsoft uses a different wchar_t from the rest of the world - grrr...
> #ifdef WIN32
>  DEBUGCODE {fprintf(stderr, "WIN32, using UTF-16LE for wchar_t\n");}
>  conv_descr = iconv_open("UTF-8", "UTF-16LE");
> #else
>  conv_descr = iconv_open("UTF-8", "UTF-32");
> #endif
> 
>  bytes_converted = iconv(conv_descr,
>                          &wchar_t_Start, &in_length,
>                          &UTF8_Start, &out_length);
> 
> and so forth.
> 
> On Mac, the UTF-32 version gets selected, but it doesn't work.
> 
> So, as a quick fix:
> 1. is a Mac wchar_t string UTF-32BE, UTF-32LE, or something else?
> 2. what is the best preprocessor symbol to test for (i.e. __APPLE__,
> MACOSX, etc) to know if we are building for the Mac?  This same code
> may also be built with CMake.

It seems like having to know this stuff a priori would partly defeat the
purpose of having iconv? According to the iconv_open man page, you can
pass "wchar_t" as tocode or fromcode and it will be interpreted as
defined by the machine, OS and current locale.

- Josh


More information about the macports-dev mailing list