ka2_mail at yahoo.com
Tue Nov 30 05:40:20 EST 2004
--- John Meacham <john at repetae.net> wrote:
> 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
- 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
> > - 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.
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
More information about the Glasgow-haskell-users