More on Ptr types

[Alastair Reid]

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        reid at cs.utah.edu        http://www.cs.utah.edu/~reid/