Hi, "Kjetil S. Matheussen" <[EMAIL PROTECTED]> writes:
> I gave it a try. Unfortunately, I was completely unable to create > the configure file right now, so the patch is against 1.8.5 (sorry > if this creats trouble against git repository), and > it's also untested, since I couldn't build configure. You have to make sure you are on the `branch_release-1-8', and then "autoreconf -vfi" should suffice to produce everything. Autoconf 2.61, Automake 1.10 and Libtool 1.5.26 is all you need. > The only thing I'm not too sure about is whether > the new SCM_I_GSC_T_UINTPTR type in configure.in will actually be > optional or not. I just copied the checking code for the optional > SCM_I_GSC_T_UINT64 type though: I think this type shouldn't be optional, because there will always be a pointer-sized integer type (whereas there could be platform without 64-bit integers). >> That said, using a Scheme integer to represent a pointer wouldn't be >> efficient (pointers would likely translate to bignums). > > I think cleaner code would usually be more important in this case, > but at least there will be a choice. I'm not sure how much cleaner this is. Usually, you'll want disjoint Scheme types, which means you'll end up enclosing the pointer-as-bignum in a structure or SRFI-9 record or similar. This leads to even more overhead. Conversely, using an opaque field in a Guile struct has the same effect but with much less overhead. Another issue is that of memory management. When using pointers-as-bignums, all the GC will see is a collection of bignums, not knowing that these are actually pointers to C objects that should not be GC'd unless the integer is no longer used---as opposed to "no longer referenced"! This actually makes it mandatory to enclose the integer in a structure or similar, and then to have a guardian on that structure to allow the C object's destructor to be called when that structure is no longer referenced. (Note that it could be a valid approach in some compiler environments. It just doesn't fit well with Guile's design.) Anyway, it can't hurt to have the choice. :-) Thanks, Ludovic. PS: You'll have to assign copyright to the FSF so that your code can be integrated. We can discuss it off-line if you want.