More on Ptr types

[George Russell]

Alastair Reid 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.
[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.

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.