--- John Meacham
The problem is that these operations are very unsafe, there is no guarenteed isomorphism or even injection between wchar_ts and Chars. If people really know what they are doing, they can do the conversion themselves via fromIntegral/ord/chr, but I don't think we should encourage such unsafe usage with functions when it is simple for the user to work around it themselves.
As I understand castCWcharToChar is unsafe if the language doesn't support unicode /* Char type is too small */ and castCharToCWchar is unsafe if in the target OS wchar_t has 16 bits while the language supports unicode. In both cases String<->CWString traslation is safe. When I have wchar_t in C then I have two opportunities: - map the type in Haskell to CWchar without any conversion - use chr.fromIntegral or fromIntegral.ord The first variant is more portable. Please correct me if I am wrong. Are castCCharToChar and castCharToCChar deprecated? I think castCharToCChar is unsafe when the language supports Unicode.
- CWchar type looks a little bit strange compared to CChar, CString and CWString types. In my opinion CWChar looks more consistent.
I originally had it as CWChar, but it was changed to CWchar to conform to the already written FFI spec which defined the wchar_t equivalant to be CWchar
Maybe the FFI spec should be fixed but I don't think that the issue is so important because it is a matter of taste. I can live with CWchar for now. Cheers, Krasimir __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com