ANN: H98 FFI Addendum 1.0, Release Candidate 15
Release Candidate 15 with all the changes discussed since RC13 is now available from http://www.cse.unsw.edu.au/~chak/haskell/ffi/ The only open problem are a set of questions raised by Simon and Ross to which I have previously answered with another set of questions (see the attached message), which is were the discussion stopped. In order to get it going again, I propose the following: * We require from a FFI library implementation only that it supports CWString and the associated functions on platforms, which are Marlow sensible. * On other platforms a FFI library is free to do what it wants (eg, not support these functions at all or attempt to implement something similar). And here now a probably naive question of mine: Does the notion of Marlow sensibility coincide with platforms that follow ISO/IEC 10646? Cheers, Manuel -=- Changes since RC14: * 6.2: CWChar -> CWchar * 6.3: - CWChar -> CWchar - Stated explicitly that memory allocated by `newCString' and friends can be deallocated by `MarshalAlloc.free' - Improved documentation Changes since RC13: * 5.3: Fixed typo * 5.7: Fixed a mistake in the type of `peekByteOff' and `pokeByteOff' (the type variable constrained by `Storable' must be different from the parameter of the `Ptr') * 6.3: Improved documentation
On Wed, Nov 12, 2003 at 04:57:09PM +1100, Manuel M T Chakravarty wrote:
The spec is silent on how exactly a Haskell Char is translated to a CWchar, and there aren't any conversion functions ala castCharToCCHar / castCCharToChar.
Hmm, should we maybe have a `castCharToCwchar' and `castCwcharToChar'?
I didn't include those in my sample implementation in case the conversion was non-trivial, whether we want to support non-trivial conversions is another matter. I would prefer not to add them unless we want to specifically not support non-unicode wchar_t implementations. an overly restrictive constraint IMHO.
So presumably the expected behaviour is that the implementation does its best to translate between Unicode Char and whatever encoding the prevailing C library is using for wchar. Any sensible implementation will be using Unicode for wchar too, so the translation will be a simple no-op, but the C standard doesn't specify this. Older systems will probably have a locale-dependent encoding for wchar. The GNU C library has a slight bug in this regard, too (see previous discussion).
I expect that when we implement the CWString operations for GHC we won't bother with any locale-dependent translations, so the implementation will only work on "sensible" systems.
There is a fair bit that is non-obvious here, so I feel the spec ought to say something.
Yes, I agree. The question is, what do we actually want for the standard? Do we want to restrict the standard to only work for "sensible" systems? If so, what is the proper phrase to identify "sensible" systems?
well, the defining factor of where my routines work is when wchar_t represents unicode code points. this may or may not be locale dependent, on glibc based systems, wchar_t is ALWAYS unicode and it #defines something to that effect so this can be determined at compile time. on other systems (like solaris, and I think the BSDs) it appears that wchar_t is almost always unicode. a run-time test can determine if this is the case so my routines will still work. (note: i have not implemented this run-time test, but it shouldn't be difficult.) note that there is no theoretical reason not to support odd encodings, the iconv framework will let us convert directly from unicode to whatever wchar_t and char encoding are appropriate. It may not be worth implementing just yet due to the hassle and perhaps limited usefulness. However I don't think the FFI spec should artificially constrain itself based on the spurious limitations of current implementations. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------
On 12-Nov-2003, Manuel M T Chakravarty <chak@cse.unsw.edu.au> wrote:
And here now a probably naive question of mine: Does the notion of Marlow sensibility coincide with platforms that follow ISO/IEC 10646?
Do you mean platforms whose C implementation defines __STDC_ISO_10646__, i.e. whose wchar_t values are represented using the encoding specified by ISO/IEC 10646? -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
Fergus Henderson <fjh@cs.mu.oz.au> wrote,
On 12-Nov-2003, Manuel M T Chakravarty <chak@cse.unsw.edu.au> wrote:
And here now a probably naive question of mine: Does the notion of Marlow sensibility coincide with platforms that follow ISO/IEC 10646?
Do you mean platforms whose C implementation defines __STDC_ISO_10646__, i.e. whose wchar_t values are represented using the encoding specified by ISO/IEC 10646?
Yes. Manuel
participants (3)
-
Fergus Henderson -
John Meacham -
Manuel M T Chakravarty