pika-dev
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]