More on Ptr types

[Alastair Reid]

> By the way, you lot are aware that under the old ANSI C standard at
> least, pointer types can have different sizes depending on the type?
> Thus a pointer to a properly-aligned 64-bit entity needs 3 less bits
> than one to an 8-bit entity, and implementations are entitled to use
> this.  The only guarantee I can remember is that (void *) is big
> enough to represent everything.  Does this affect things at all?

C has its faults but at least it was easy to understand what things
meant (albeit in a very low-level manner) and the various
implementation options.  Then along come the standards organizations
and everything that was simple gets complicated.

I can see exactly why they did this (e.g., I'm currently working with
an embedded processor that uses 16-bit addresses to index its 128K
16-bit-aligned instruction space and 12-bit addresses to index its 4K
8-bit aligned data space) but... ugh!

I'm not sure whether it needs a change in the ffi implementations
unless the function calling convention on some platform were to pass
these pointers differently.  But, let's imagine a pointer to an
aligned 64K object in a 32-bit address space being stored in just 16
bits.  I think the only change we'd need in the ffi spec to accomodate
this is:

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*.

As long as  

  forall alpha. sizeof(HsPtr) >= sizeof(alpha*)

I think the rest of the FFI spec is fine because the Haskell side
never tries to do anything with a pointer - it just treats it as a
curious looking bit-pattern that the C world would like it to hang
onto for a while (or, in less anthropomorphic language, it is an
opaque/abstract datatype).


-- 
Alastair Reid        reid at cs.utah.edu        http://www.cs.utah.edu/~reid/