Alastair Reid wrote: [snip] > Any casting between Ptr types (and FunPtr, StablePtr, etc.) has to > apply the appropriate bit-shift (or whatever transformation is > required). The simplest way to handle this may be to remove all the > cast* functions from the ffi spec so that they have to be done in the > C world (which understands these things). If this were simply > intolerable (I must confess I don't know why we have them), I guess > I'd define a ForeignCastable typeclass providing appropriate > operations to cast to and from the equivalent of void*. [snip] Also I think something would need to be done to allow the user to interface to C libraries which need pointers to their own types (as in my first example). You don't know whether DB * is a pointer to char, or int, or whatever. Also the suggested solution
data DB -- note that we have no constructors foreign import ... :: blah -> IO (Ptr DB) does not necessarily guarantee that a Ptr DB is actually able to represent a DB *, whatever it is. So my suggestion would be that (1) a data DB (or any other type with constructors) would be regarded as like C's type void, so that casting to a Ptr DB and back from any other pointer type will preserve the pointer. (2) the implementation be required to perform any necessary casting between pointer types in argument and result types. Then if a DB * is actually a pointer to a 4-byte quantity (say), it will silently cast from Ptr DB. I hope this would not in fact be too hard; where a C compiler is used to read the header file, calling an import'd function with non-matching pointer types one hopes the compiler will insert the relevant casts. Still these are deep waters; if this issue is to be addressed perhaps someone should check the latest copy of the C standard and see if it still exists. (I think Harbisson & Steele's reference to standard C mentions a machine where differing pointer sizes actually occur, but I don't know if any are still around.) _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
