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