> Briefly, GreenCard has always marshalled Word8 as a Word32 (and so has
> Hugs). I'm wondering if a recent change in GHC or in how Win32 is
> compiled might have changed the way that Word32 is being marshalled.
>
> Possibilities:
>
> Maybe GHC has started marshalling word32 differently?
>
> Maybe a change from ccall to ffi happened and they do different
> things?
>
> Maybe the October 2001 removal of --target ffi
>
> Am I right in thinking that ccall was recently removed from GHC
> so now everything goes through the ffi?
>
> Not sure yet what the problem is but it seems a plausible
> place to look.
> Hope this triggers some ideas
We're groping around in the dark here - I don't suspect this
word8/word32 issue is the cause of the problem, but it looks a bit odd.
Someone (Hal?) needs to run gdb on the misbehaving program and find out
which function is getting passed bogus arguments, and we can work from
there.
There haven't been any recent changes to low-level marshaling, and we
haven't removed _ccall_ or _casm_ yet (although I'd dearly love to, but
there's still code that uses it).
> GHC's StdDIS.gc looks like this
> (fptools/green-card/lib/ghc/StdDIS.gc):
>
> %dis word8 x = < fromIntegral / fromIntegral > (word32 x)
>
> which means:
>
> to marshall (convert from Haskell to C) a word8, apply fromIntegral
> and then marshall as a word32.
>
> That seems to be what is going on here.
>
> Looking back in the log, this has been the marshalling rule for word8
> for as long as there has been one (since January 1998) and it is the
> current rule for Hugs.
Then I don't understand how it works! If the caller is placing Word32's
on the C stack, and the C function is expecting to pull Word8's off the
stack, it might "work" on a little-endian machine because the value will
be transferred in the lowest byte. The size of the argument on the C
stack is a Word32 in both cases (I believe the size is always promoted
even if the value is not, to retain 4-byte alignemt of stack values).
On a big-endian machine I'd expect this to break. Does it?
> Why do we marshall 8 bit ints as 32 bit ints?
>
> I think we're promoting 8 bit ints up to 32 bit ints because that's
> what (we believe) the C compiler does on this platform. Why do this
> ourselves instead of letting the C compiler do it itself? It probably
> dates back to the days when GHC's ccall didn't have a marshalling rule
> for 8 bit ints - no problem, we thought, we know it will just turn
> into a 32bit int so let's do that manually.
>
> But, as recently discussed on the ffi list, C compilers are free _not_
> to promote if they have a prototype so _maybe_ some of the C code is
> being compiled with a prototype and some of it is being compiled
> without?
If you compile this code with a prototype using -fvia-C it might fail -
because the C prototype doesn't match Haskell's idea of the type of the
function.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
