If I understand you correctly, your concern is that a pointer
argument/result might be passed differently depending on what it is a
pointer to.
We already have a special case for FunPtr because they can be
different sizes from normal Ptrs (especially on a Harvard
architecture). What I think you're suggesting is that we might
need to make a special case for other pointer types too.
This feels like a very unlikely thing to happen and I don't understand
it yet so I propose the following (btw note that I don't speak for the
whole FFI group).
Put off acting on this until we find a platform like this. I believe
that all currently supported platyforms are not like this because if
they were we'd have noticed when we ported the compiler to this
platform.
On finding a platform like this, we can do one of:
1) Define a new calling convention ccall-plus (or whatever) which is
just like the ccall convention except that the extloc strings can
contain extra information to resolve the problem.
2) Require any affected functions to go through C wrappers which do the
coercion.
My feeling is that this will be viable because I suspect there
would be something very unusual about the pointers which are passed
differently (e.g., they will be pointers into I/O space or pointers
to 32-bit aligned memory) so they will be rare and easy to find.
3) Find a way to add the missing type information to the Haskell type.
I think this is much more than being careful to use
Ptr (Ptr DB)
instead of
Ptr DB
because I would be hugely surprised if void* and void** had different
representations. Rather, I think any differences would only show
between types like these:
char*
char[1 << 16] *
char[1 << 32] *
Haskell doesn't have a notion of sized types so we would deal with this
either by extending Haskell (yoiks!) or by encoding the information
using something like this:
data Ptr8 a -- pointer to 8-bit aligned object
data Ptr16 a -- pointer to 16-bit aligned object
data Ptr32 a -- pointer to 32-bit aligned object
data Ptr64 a -- pointer to 64-bit aligned object
That is, we'd extend the FunPtr approach in some appropriate way.
(Even if Haskell did have a notion of sized types, it wouldn't be
enough because I'll bet there would be non-standard extensions which
let C programmers override the default alignment of a type.)
--
Alastair Reid [EMAIL PROTECTED] http://www.cs.utah.edu/~reid/
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
