Ross Paterson <[EMAIL PROTECTED]> wrote, > On Thu, May 22, 2003 at 07:05:38PM +1000, Manuel M T Chakravarty wrote: > > Ross Paterson <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi