CStrings

Marcin 'Qrczak' Kowalczyk mk167280 at students.mimuw.edu.pl
Tue Nov 28 12:35:41 EST 2000


On Tue, 28 Nov 2000 malcolm-ffi at cs.york.ac.uk wrote:

> What do you mean by "absent"?  I thought you had a proposal.  I was
> just asking for it to be recognised as a proposal rather than a
> standard, because we haven't had any experience with using it yet.

Ok.

> Just by looking at the names and type signatures, I'm not even
> sure what each proposed function does.  Could you describe them in
> a little more detail?

Sorry, I thought it was clear from names and types.

  peekCString    :: Ptr CChar -> IO String
  -- Read a null-terminated string of C chars from memory and convert
  -- it to Haskell string. The C string is assumed to be in the default
  -- local byte encoding.
  peekCStringLen :: Ptr CChar -> Int -> IO String
  -- Similarly, but read the specified number of chars instad of searching
  -- for '\0'.

  withCString    :: String -> (Ptr CChar -> IO a) -> IO a
  -- Convert a Haskell string to the null-terminated C string in the
  -- default local byte encoding, stored in some temporary memory.
  -- Apply the function to the pointer to that string, execute the
  -- resulting action and then free the string.
  withCStringLen :: String -> (Ptr CChar -> Int -> IO a) -> IO a
  -- Similarly, but tells about the length of the converted string,
  -- not including the final '\0'. This allows converting strings
  -- containing null characters.

  newCString     :: String -> IO (Ptr CChar)
  newCStringLen  :: String -> IO (Ptr CChar, Int)
  -- Like withCString*, but the memory is obtained by malloc. It must be
  -- explicitly freed using free.

> My request for a portable implementation is because, now that the
> basic common FFI is settled, I believe we should be using it to ensure
> that new proposals such as yours are not restricted to GHC-only,
> like so many existing libraries sadly are.

The C string stuff can be written portably in Haskell implementations
which use the same character encoding as C instead of Unicode. That
implementation will not be valid when Strings really use Unicode.

The generic interface for charset conversions is not established yet. I
have a proposal for it, but there is much room for choice there. Having
such interface it is possible to write the C string functions in an
inefficient way. My proposal for charsets allows having more efficient C
string functions than can be written using its official interface
(avoiding going through Haskell lists of CChars or Bytes). In practice the
implementations of Unicode stuff and C string stuff are mutually
dependent.

-- 
Marcin 'Qrczak' Kowalczyk





More information about the FFI mailing list