ANN: H98 FFI Addendum 1.0, Release Candidate 9

[Manuel M T Chakravarty]

Ross Paterson <ross at soi.city.ac.uk> wrote,

> On Thu, May 22, 2003 at 07:05:38PM +1000, Manuel M T Chakravarty wrote:
> > Ross Paterson <ross at soi.city.ac.uk> wrote,
> > > and HsStablePtr constrained to (void *)?
> > 
> > This is a kludge.  Essentially, we would like an abstract
> > type and (void *) is the closest you get in C (and what is
> > typically used in C APIs for the same purpose).  It is
> > important to be concrete about the type to fix the storage
> > requirements.
> 
> I don't follow you.  Why is it necessary to be more concrete than HsInt
> and HsFloat?  We don't know exactly what they are, but we know we can use
> sizeof, and assign them, etc.  Why can't HsStablePtr just be constrained
> to be a scalar type?

StablePtr are used to export references to Haskell values to
C, where they are treated as abstract data.  In C one
traditionally uses (void *) for that purpose (see "man
qsort(3)").  We want to make sure HsStablePtr is not to wide
to be passed as an argument to C functions expecting such
abstract types (such as qsort(3)).

sizeof is of little help here.  The C compiler will have
allocated a fixed amount of storage when it compiled the C
library.  Our type fits in there or not.  All you can do
with sizeof is to add an assertion that aborts the program
in case of a mismatch.

John Meacham <john at repetae.net> wrote,

> There is also uintptr_t and intptr_t, integral types guarenteed to be
> able to hold a  (void *). very handy for storing a token which might be
> a number or pointer and you want to be able to safely cast between them.

Again I am worried that C libraries, which tend to use (void
*) not uintptr_t or intptr_t will mismatch with out
definition of HsStablePtr.

Cheers,
Manuel