Use of H98 FFI

[Manuel M T Chakravarty]

Peter Thiemann <thiemann@informatik.uni-freiburg.de> wrote,

> I recently had my first exposure to Haskell's FFI when I was trying to
> compute MD5 and SHA1 hashes using the existing C implementations. In
> each case, the idea is to make the hash function available as function
> 
> > md5 :: String -> String
> 
> However, the naive implementation
> 
> >     md5_init md5_state
> >     n <- newCString str
> >     md5_append md5_state n (fromIntegral (length str))
> >     md5_finish md5_state md5_digest
> 
> does not scale to computing hashes of really long strings (50 MB, say,
> as arising from reading a moderately big file), since it tries to
> create a CString of that size, first! 
> 
> Trying to avoid the allocation of this giant CString requires to split
> up the original string into smaller parts and convert each part to a
> CString separately. Clearly, this task involves a lot of allocation,
> essentially the input string needs to be copied part by part.
> 
> Hence, I was wondering why the FFI only provides functionality to
> convert an *entire* list of Char into a CString. For applications like
> this hash computation, it would be advantageous to be able to specify
> *how much* of the input string to marshall to the CString and have the
> conversion function return the rest of the input string and the
> CString. That is, in addition to 
> 
> > newCString :: String -> IO CString
> 
> there should be
> 
> > newCStringPart :: String -> Int -> IO (CStringLen, String)
> 
> or even
> 
> > toCStringPart :: String -> CStringLen -> IO (Int, String)
> 
> where CStringLen describes a target buffer into which the String
> argument is to be marshalled.  (and similarly for other list types)

The idea of the FFI Addendum is to provide the *basic*
functionality needed for using foreign code from Haskell.
However, it was explicitly never the aim to cover all
possibly needed idioms.  Instead, we expect that FFI tools
(such as GreenCard or C->Haskell) and additional support
libraries provide this coverage by mapping more complex
marshaling requirements down to the basics described in the
FFI Addendum.

> Clearly, I can program this functionality by hand. But I have to
> revert to byte-wise processing using pokeByteOff, castCharToCChar, and
> so on. In addition, the optimizer does not seem to be very effective on
> such code, so it seems advantageous to provide it in the library
> already.

As Sven already pointed out, it seems like you should use
Word8 instead of Char (which is unicode-based).  The FFI
libraries don't do anything but use pokeElemOff and friends
themselves.  So, performance-wise there will be no
difference.  For `pokeArray', the libraries use

pokeArray :: Storable a => Ptr a -> [a] -> IO ()
#ifndef __GLASGOW_HASKELL__
pokeArray ptr vals =  zipWithM_ (pokeElemOff ptr) [0..] vals
#else
pokeArray ptr vals = go vals 0#
  where go [] n#         = return ()
	go (val:vals) n# = do pokeElemOff ptr (I# n#) val; go vals (n# +# 1#)
#endif

ie the GHC code makes use of unboxed values, though.

Cheers,
Manuel

PS: It might be useful to provide the functions you describe
    as part of the hierachical libraries, though.