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
--- Begin Message ---
"Simon Marlow" <[EMAIL PROTECTED]> wrote,
> > I have put RC 14 at
> >
> > http://www.cse.unsw.edu.au/~chak/haskell/ffi/
> >
> > including all the feedback on RC13. Please especially have
> > a look at Section 6.3 (Section "CString"), where some of the
> > wording changed.
>
> 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'?
> 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?
Cheers,
Manuel
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
--- End Message ---
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
