On Friday 16 March 2007 15:10, Ian Lynagh wrote:
I'm not clear on exactly what you're proposing: would
getDirectoryContents "." >>= mapM_ removeFile
remove all the files in ".", regardless of what my locale is, my OS is, etc? i.e. would this solve my problem in
http://www.haskell.org/pipermail/libraries/2005-July/004189.html
OK, let's make this a bit more concrete and let's take Mac OS X as an example. On this platform, peekCString would decode from UTF-8 to Unicode (probably normalizing the Unicode string on the way), so no information is lost. OTOH, withCString would encode the Unicode string to UTF-8 (decomposing on the way? Wolfgang?). Both functions are used by getDirectoryContents internally, so this will be "Unicode-enabled" then, too. The main point here is that UTF-8 => Unicode => UTF-8 is lossless, and the same holds for my proposed change for *nices, too, as long as the local encoding is invertible in this sense. I am not sure if there are encodings in use out there which do not have this property, but even if they are: All e.g. Qt-based programs would share the same problems. For Windows platforms we should use the "wide" API internally, and the CString functions would be equivalent to their CWString counterparts. For older Windows versions we could fall back to "current ANSI code page", if we want to support those still. Of course this means that we e.g. can't use a single __hscore_open anymore (or we'll have to do some more cpp trickery to get the char vs. wchar_t problem right), but I think that the effort is manageable and can be done in a piecewise fashion. Cheers, S.