[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pika-dev] Re: Guile FFI wrapper, t_scm_word ambiguity
From: |
Tom Lord |
Subject: |
Re: [Pika-dev] Re: Guile FFI wrapper, t_scm_word ambiguity |
Date: |
Sat, 31 Jan 2004 12:27:42 -0800 (PST) |
> From: Andreas Rottmann <address@hidden>
> I started the wrapper anew, since I realized it would probably make
> sense to plug Guile in as just another "rep", i.e. leaving libscm/
> mostly intact an modifying the stuff in reps/ to be just a thin layer
> above Guile.
Thank you! Yes, I think that that's an excellent idea.
> So far, with a bit of preprocessor magic, this seems work really
> well.
> However, since in libscm/words.h I have
> typedef SCM t_scm_word;
DOH! That's a gosh-darn bug. src/pika/libscm/words.[ch] should
really be called src/pika/reps/words-imp.[ch].
There should be a replacement file in src/pika/libscm/words.h which
does nothing but #include the reps copy.
> And SCM is supposed to be opaque (and happens to be implemented as
> pointer normally), I wondered if it wouldn't be appropriate to make
> t_scm_word an opaque type too. ATM, t_scm_word is used both to denote
> a "scheme value" and an unsigned integer (e.g. all the hash functions
> return a t_scm_word). I had to replace these uses of t_scm_word with
> t_ulong.
> So these options seem to exist:
> 1) Just s/t_scm_word/t_ulong/ where apropriate for the Guile Pika FFI,
> as I've done now and leave everything the same in the "real"
> Pika.
I think that the right solution for the hash functions is:
* use t_scm_fixnum rather than t_ulong
* double check to make sure that scm_range_fix_hash_value
can't return a negative t_scm_fixnum
> 2) The same as 1), but the do the substitutions in "real" Pika.
The non-reps parts of "real" Pika (e.g., libscm/hash-values.[ch]
should _not_ be using t_scm_word as an integer type. Those are
bugs. They should be using t_scm_fixnum and should be reviewed for
sign issues and overflow issues.
The abstraction is:
t_scm_fixnum is a signed integer type large enough to hold the
largest integers that can be represented by the implementation
of fixnums in reps --- that is: it's large enough to hold the
largest integers that the non-reps parts of Pika can pass back
and forth with Scheme without using bignums.
t_scm_word is the <unspecified> type of a Scheme location.
The non-reps parts of Pika (and any FFI-using code) should
never use t_scm_word as the type of an rvalue.
> 3) Add a new typedef that replaces the t_scm_word in the places where
> it is used as plain integer.
t_scm_fixnum is that typedef.
> I'd favor 2) or 3), although I havne't yet been able to think of an
> appropriate name for 3).
t_scm_fixnum :-)
-t