Ross Paterson <ross@soi.city.ac.uk> wrote,
On Thu, May 22, 2003 at 07:05:38PM +1000, Manuel M T Chakravarty wrote:
Ross Paterson <ross@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@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