More on Ptr types
reid at cs.utah.edu
Fri Jun 7 11:12:57 EDT 2002
> 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
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
Alastair Reid reid at cs.utah.edu http://www.cs.utah.edu/~reid/
More information about the FFI