Let's get this finished

Marcin 'Qrczak' Kowalczyk qrczak at knm.org.pl
Thu Jan 4 13:26:15 EST 2001


Thu, 4 Jan 2001 02:59:05 -0800, Simon Marlow <simonmar at microsoft.com> pisze:

> Actually I consider the current libraries to be on the verge
> of usability, modulo the missing string marshalling and error
> functionality.

For both subjects I have a proposal in QForeign. I have no doubts
about the strings story, except the internals of the charset conversion
machinery. Error handling functions are more arbitrarily chosen.

> I've been wondering whether we should have something like
> 
> 	newtype CString = CString (Ptr CChar)
> 
> which would allow GHC to replace the representation with a ByteArray
> leading to a much more efficient implementation of withCString.

Do you have the overhead of malloc in mind? If so, perhaps a generic
stack allocator would be better.

Anyway, conversions between strings which involve charset conversions
require a more sophisticated pattern of memory allocation. It is
not known how much space will be needed in advance, it can only be
estimated. It is known when the string has already been stored in
some memory directly accessible to C functions (in the common case of
using the default conversion).

Doing it on ByteArrays would be very tricky. There is no reallocByteArray
and ByteArrays are not convertible to Ptrs (I currently assume that
a conversion implemented in C will be exposed as a function working
on Ptrs).

My current strategy is to use malloc directly instead of alloca.
If there was a faster alloca allocator, it could make sense to make
a guess about the size and use alloca, resorting to malloc if it
didn't fit. It would have to be significantly faster to think about
making it more complex at all. The conversion itself can be a larger
overhead than malloc.

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTÊPCZA
QRCZAK





More information about the FFI mailing list