Attached is a properly internationalized implementation of Foreign.C.String, along with some other routines which I feel would be very at home in the FFI standard. Note that I am trying to solve a simpler problem than full generic i18n. I just want the ability to work within the current locale, whatever it might be. I have tested these routines in utf8, latin1, greek, korean and a few other locales. they seem to work well. in addition to properly localeizing withCString, peek/pokeCString and friends I feel it is important to provide routines to work on wchar_t * strings. there are a number of reasons: * if __STDC_ISO_10646__ is defined (which is almost always), conversions can be incredibly optimized, in particular an array of Chars can be implemented directly as an array of wchar_t's * many c libraries nativly take wchar_t *s, converting to and from a multibyte encoding would be wasteful * wchar_t and the assosiated charset routines has been part of C since C90.1 and are quite stable. * and mainly, is is LIKELY that the current multibyte encoding is lossy compared to wchar_t. forcing people to go through char *s will break encodings for no good reason. * multiple locales are very common nowadays, not just for internationalization, but to differentiate between a utf8 based unix and a latin1 one. the routines I propose adding are: withCWString, withCWStringLen, newCWString, newCWStringLen, peekCWString, peekCWStringLen, -- same as CString counterparts charIsRepresentable :: Char -> IO Bool -- returns true if the argument can be represented in the current locale and the types CWChar, CWString, CWStringLen with CWChar == wchar_t and the others defined analogously to the CString versions. also, to a lesser extent I propose we add explicit utf8 routines: withUTF8String, withUTF8StringLen, newUTF8String, newUTF8StringLen, peekUTF8String, peekUTF8StringLen there are several libraries (X11 being a major one) which export an explicit utf8 based interface, it would be nice to be able to call their routines directly without worrying about the current locale. these might be more at home in a seperate library and not the FFI spec since they can be implemented independently, but can probably benefit from compiler dependent optimization. my implementation is pretty hairy, but can be improved. it currently only works on systems where __STDC_ISO_10646__ is defined, but fortunatly, I have never come across a system where it was not defined and it implemented wchar_t at all. the localized versions of the CString routines are named with LCString, which stands for localized C string...