[bitc-dev] C interfacing vs. portability
Jonathan S. Shapiro
shap at eros-os.com
Thu Feb 26 16:50:33 EST 2009
On Thu, Feb 26, 2009 at 12:20 PM, Sam Mason <sam at samason.me.uk> wrote:
> On Thu, Feb 26, 2009 at 09:55:09AM -0500, Jonathan S. Shapiro wrote:
>> In abstract, there seem to be two ways to handle this:
>> 1. Have a module that defines *aliases* for c_int, c_long, c_short, etc.
>> 2. Introduce c_int and friends as first-class integer types that are
>> *distinct from* the BitC types, but also define conversion functions
>> and arithmetic operations over these types.
> As always I seem to go back to Haskell, it's got a similar type system
> and the best FFI I've used to solve real problems, and it does the
> second option.
This is where I am currently leaning.
> The FFI types are
> also hidden away in the "Foreign.C.Types" module, which will tend
> to encourage people to use more appropriately defined and generally
> available types in their code.
This as well.
> How often are these types expected to be used? I'm not expecting it
> to be all that often.
Unfortunately this depends on which libraries you are interfacing with.
> What about calling conventions and C macros? Are you expecting people
> to provide C wrappers for them?
The BitC calling convention is exactly the same as C (by design). C
macros are obviously not supported, and I have no plans to do so.
More information about the bitc-dev