CWString

[Glynn Clements]

John Meacham wrote:

> 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.

But bear in mind that other programmers may want to work in the "C"
locale, regardless of the user's environment settings. This why the C
library doesn't attempt to use those settings unless the program
explicitly requests their use via setlocale().

Also, some libraries may fail to cope with locales other than "C";
particularly locales with multi-byte encodings.

> 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,

Note that the Xutf8* functions are specific to XFree86's version of
Xlib (and are only in 4.0.2 and later); they aren't in the vanilla
OpenGroup version. They don't exist in vanilla X11R6, or in XFree86 3.x.

Also those functions are redundant; you can always use the Xmb*
functions with a UTF8-based locale instead.

Simon Marlow wrote:

> In our new implementation of Data.Char.isUpper and friends, I made the
> simplifying assumption that Char==wchar_t==Unicode.  With glibc, this
> appears to be valid as long as (a) you set LANG to something other than
> "C" or "POSIX", and (b) you call setlocale() first.

The glibc Info file says:

	The wide character character set always is UCS4, at least on
	GNU systems.

> We now call setlocale() in the RTS startup code.

So anyone who doesn't want to use the current locale now has to
explicitly set it back to "C"?

Also, this is just for LC_CTYPE, right?

-- 
Glynn Clements <glynn.clements at virgin.net>