I ran into a possible problem while testing some ffi code. This is with hugs compiled for cygwin or with the windows (msi) version. Hugs says: sizeOf x::CDouble is 4, wheras 'C' says sizeof(double) is 8. I ~~think~~ I see what the problem is with sizeOf. I am using the new hierarchical libs, and it defines sizeOf by hardcoding the sizes rather then asking 'c' like the previous versions did. And sizeOf Double is coded as 4 in libraries\Foreign\Storable.hs Is there something simple I just don't understand? As a side note, is alignPtr implemented somewhere? (Alastair, I already sent this to you, but didnt sent to the list.) Gratefully, Ron
On Mon, Jan 06, 2003 at 03:42:27PM -0500, R. Legere wrote:
I ran into a possible problem while testing some ffi code. This is with hugs compiled for cygwin or with the windows (msi) version. Hugs says: sizeOf x::CDouble is 4, wheras 'C' says sizeof(double) is 8.
I ~~think~~ I see what the problem is with sizeOf. I am using the new hierarchical libs, and it defines sizeOf by hardcoding the sizes rather then asking 'c' like the previous versions did. And sizeOf Double is coded as 4 in libraries\Foreign\Storable.hs
Thanks for the report. It's a bug on all architectures, now fixed in CVS. (The sizes are computed in the configuration process, and there was some confusion about doubles.) A workaround is to change that 4 to an 8.
As a side note, is alignPtr implemented somewhere?
Not in the Nov 2002 release. The CVS version has alignPtr :: Ptr a -> Int -> Ptr a alignPtr p n = p `plusPtr` ((n - ptrToInt p `mod` n) `mod` n)
On Mon, Jan 06, 2003 at 03:42:27PM -0500, R. Legere wrote:
Hugs says: sizeOf x::CDouble is 4, wheras 'C' says sizeof(double) is 8.
Incidentally, notice that Double and Float have the same representation in Hugs so Hugs' internal representation of HsFloat and HsDouble will not be float and double. Rather, it will be float and float or double and double. This is probably where the confusion stems from. Fixing this situation has been on my todo list for some time though I'd be happy to put it on someone else's todo list instead. All the bits are in place to fix this - it's just a question of systematically going through all the relevant parts making them use the right representation. -- Alastair Reid alastair@reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/
participants (3)
-
Alastair Reid -
R. Legere -
Ross Paterson