Hackage :: [Package]

c-storable: CStorable class

[ bsd3, development, haskell, library ] [ Propose Tags ] [ Report a vulnerability ]

Replacement for Storable class that omits non-C types

[Skip to Readme]

Downloads

Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees

Candidates

  • No Candidates
Versions [RSS] 0.1, 0.2, 0.3
Dependencies base (<5) [details]
Tested with ghc ==7.8.4, ghc ==7.10.3, ghc ==8.0.2
License BSD-3-Clause
Author Evan Laforge
Maintainer Evan Laforge <qdunkan@gmail.com>
Category Haskell, Development
Home page https://github.com/elaforge/c-storable
Source repo head: git clone git://github.com/elaforge/c-storable.git
Uploaded by EvanLaforge at 2020-07-19T21:57:19Z
Distributions NixOS:0.3
Reverse Dependencies 1 direct, 0 indirect [details]
Downloads 1641 total (7 in the last 30 days)
Rating (no votes yet) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs available [build log]
Last success reported on 2020-07-19 [all 1 reports]

Readme for c-storable-0.3

[back to package description] 
When binding to C via hsc2hs, you are expected to write your own Storable
instances, and manually poke struct fields with any Storable type.  Since all
manner of non-C types are in Storable, it's easy to accidentally poke a Char
instead of CChar, at which point you have memory corruption that may be very
difficult to track down.

One such bug was enough for me, so I created a parallel CStorable class that
prevents that kind of bug by only including C types.

If you are writing a new C binding, I recommend something higher-level than
hsc2hs, such as c2hs, which I think should sidestep the problem entirely by
verifying your types.  But if you are already using hsc2hs and for whatever
reason don't want subtle memory corruption bugs, you can import ForeignC
instead of Foreign and Foreign.C, and see if you have any.