This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
Date: Sun, 4 Jan 2004 17:21:41 -0800 (PST)
From: Tom Lord <lord@xxxxxxx>
The draft FFI says:
double SCHEME_EXTRACT_DOUBLE(scheme_value)
char * SCHEME_EXTRACT_STRING(scheme_value)
Neither says "(may GC)".
If I'm using some exotic number representation (constructive reals,
perhaps), then EXTRACT_DOUBLE may very well involve some pretty hairy,
hence possibly GC-causing, computation.
This doesn't worry me too much; there aren't a lot of such
implementations around.
If I'm using some exotic string representations (I'm working on a
functional-splay-tree string type for Pika) -- same deal:
extract-string may take some (possibly GC-causing) work.
This does worry me (it's listed in the 'issues' section of the SRFI).
I think we went overboard here. Something like
SCHEME_EXTRACT_STRING_CONTENTS(scheme_value, index, count, buffer)
which copies 'count' characters starting from 'index' into 'buffer'
would be better. Presumably this can be done without GCing.
Even something innocent like:
int SCHEME_CHAR_P(scheme_value)
can cause GC if my implementation let's me attach to a hook in its
implementation.
Again, I don't think this will be very common. Is there an existing
implementation for which this (or anything similar) is an issue?
-Richard Kelsey