More on Ptr types

[Alastair Reid]

> [snip] Unfortunately there appears to be no way this can be fixed in
> general for ANSI C without parsing the header file.  For example if
> DB is an external type unknown to the Haskell compiler, and a
> function requires us to pass in a **DB, to which it writes a *DB as
> output, we cannot interface to it without knowing what sort of
> pointer a *DB is, since we cannot create a Ptr (Ptr DB) which will
> correspond to a **DB in any useful way.  So we will just have to
> cross our fingers and hope it doesn't happen.

The ffi philosophy is to provide a mechanism out of which more
convenient tools can be built.  There's nothing to stop an external
tool from doing this parsing.

Indeed, that's what you have to do when interfacing to something like
Xlib.  Just how big an int is each of the umpteen integral types in
Xlib?  Which ones are the same size on all platforms and which are
different sizes?  Probably the best way to figure it out is to write a
small script along the lines of:

#include "X.h"
main() {
  printf("sizeof(Display*) == %d\n", sizeof(Display*));
  printf("sizeof(Window*) == %d\n",  sizeof(Window*));
  ...
}

> It's not just a question of differently-sized words.  For MMIX
> (which already has a gcc port) while pointers all have the same
> size, the bottom bits are junk (simply ignored) so compilers might
> conceivably zap these bits during casts and use them to store other
> information.

Ok, if they're passed the same way and all we have to do is respect
the bottom bits, that's easy.  Don't use the cast functions provided
by the Foreign libraries and all will be cool.  (We might want to do
an audit of the libraries to determine which other functions use the
cast functions.)

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