Evan Laforge | 2 Jan 00:17 2013
Picon

hsc2hs and Storable (especially) unsafe

It so happens that on 64 bit OS X, haskell's Int is 64 bits, while C's int is
32 bits.  hsc2hs's #poke does no typechecking at all, so if you have

(#poke Struct, int_field) structp int -- where int :: Int

Then you probably are going to corrupt memory, and in a particularly
pernicious way (since chances are it won't segfault).  Similarly, don't poke
haskell Chars, it has to be CChar.  And what's even worse,
Foreign.withArrayLen gives you an Int, not a CInt!  So doing the obvious thing
and poking the pointer and length directly is wrong.  And besides, shouldn't
it be a CSize?  Another trap: C++'s bool is probably one byte, haskell's Bool
Storable says it's 4.  It's probably not even correct to assume Double =
CDouble and Float = CFloat, though it seems likely to be always true.

I carefully vetted all my #pokes but I'm annoyed that hsc2hs and Foreign let
me get away with this.  If Storable is for marshalling types to and from C,
then non-C types should not be Storable!  If Storable is useful for other
things (and it is!), then Foreign should define its own CStorable, that only
includes C types, and hsc2hs should use that!

While we're at it, fromIntegral is not a safe way to convert a haskell type to
a C one.  But it sure is a tempting one, because Foreign.C doesn't provide any
conversion functions (except for Bool).  We should have explicit conversion
functions that give the choice of crashing with an error or clamping the
number to the (smaller) C type's bounds.  I'm not sure if anyone wants what
fromIntegral does.

Or maybe I shouldn't be using hsc2hs in the first place.  I feel more and more
that it gives haskell a bad name, being low level and error prone.  I used
bindings-dsl for a libgit2 binding, and at least it automates Storable
(Continue reading)

Simon Peyton-Jones | 2 Jan 10:08 2013
Picon

FW: [Haskell-cafe] hsc2hs and Storable (especially) unsafe

Food for thought here.

Simon

| -----Original Message-----
| From: haskell-cafe-bounces <at> haskell.org [mailto:haskell-cafe-
| bounces <at> haskell.org] On Behalf Of Evan Laforge
| Sent: 01 January 2013 23:18
| To: haskell
| Subject: [Haskell-cafe] hsc2hs and Storable (especially) unsafe
| 
| It so happens that on 64 bit OS X, haskell's Int is 64 bits, while C's
| int is
| 32 bits.  hsc2hs's #poke does no typechecking at all, so if you have
| 
| (#poke Struct, int_field) structp int -- where int :: Int
| 
| Then you probably are going to corrupt memory, and in a particularly
| pernicious way (since chances are it won't segfault).  Similarly, don't
| poke haskell Chars, it has to be CChar.  And what's even worse,
| Foreign.withArrayLen gives you an Int, not a CInt!  So doing the obvious
| thing and poking the pointer and length directly is wrong.  And besides,
| shouldn't it be a CSize?  Another trap: C++'s bool is probably one byte,
| haskell's Bool Storable says it's 4.  It's probably not even correct to
| assume Double = CDouble and Float = CFloat, though it seems likely to be
| always true.
| 
| I carefully vetted all my #pokes but I'm annoyed that hsc2hs and Foreign
| let me get away with this.  If Storable is for marshalling types to and
| from C, then non-C types should not be Storable!  If Storable is useful
(Continue reading)

Stephen Paul Weber | 2 Jan 16:24 2013
Picon

Re: FW: [Haskell-cafe] hsc2hs and Storable (especially) unsafe

Somebody claiming to be Simon Peyton-Jones wrote:
>| It so happens that on 64 bit OS X, haskell's Int is 64 bits, while C's
>| int is
>| 32 bits.  hsc2hs's #poke does no typechecking at all, so if you have
>|
>| (#poke Struct, int_field) structp int -- where int :: Int

One should not do this.

That said, the tool should not allow this.

>| It's probably not even correct to
>| assume Double = CDouble and Float = CFloat, though it seems likely to be
>| always true.

base has a configure check for these, but I have been unable to determine 
what it does.  It fails on my QNXNTO cross-compiler and so I've been 
manually hacking this assumption in there, but ... yeah ... probably not 
safe.

>| I carefully vetted all my #pokes but I'm annoyed that hsc2hs and Foreign
>| let me get away with this.  If Storable is for marshalling types to and
>| from C, then non-C types should not be Storable!

Well, except that you might just be round-tripping some Haskell data through 
(void*) in C, and so the interpretation on the C side does not matter in 
that case.

>| While we're at it, fromIntegral is not a safe way to convert a haskell
>| type to a C one.  But it sure is a tempting one
(Continue reading)


Gmane