More on Ptr types

Fergus Henderson fjh at cs.mu.OZ.AU
Mon Jul 22 04:07:12 EDT 2002


On 11-Jun-2002, Alastair Reid <reid at cs.utah.edu> wrote:
> 
> 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.

On word-addressed machines, `void *' will most likely have a different
representation than `void **'.  `void *' will require additional bits to
distinguish which byte within the word is being pointed to, but `void **'
is guaranteed to point to a word-aligned `void *', so these additional
bits are not needed.

On word-addressed machines, there are usually two representations for
pointers: most pointers are represented using the native machine
representation, but pointers of type `char *', `signed char *',
`unsigned char *', and `void *' need a different (and probably larger)
representation, because they can point to bytes within a word.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.



More information about the FFI mailing list