[cffi-devel] [PATCH] 64-bit support for Allegro, and allocate stack objects in the static area

John Fremlin jf at msi.co.jp
Thu Jan 8 04:55:45 UTC 2009


Stephen Compall <s11 at member.fsf.org> writes:

> John Fremlin <jf at msi.co.jp> writes:
>>> > I'm asking these questions because I suspect both changes break with
>>> > older versions of Allegro but I can't test it since the express
>>> > edition 7.0 is no longer available. It's probably not a big deal but
>>> > I'd like to at least try to maintain compatibility.
>>> 
>>> There is no :foreign-address type in Allegro 8.1?
>>> 
>>> It is a very strange idea that there ever would be such a type. . .
>>> 
>>> http://www.franz.com/support/documentation/current/doc/ftype.htm
>>
>> Why are you ignoring this patch?
>
> A delay of 3 days is hardly an abrupt dismissal.  Furthermore, I do not
> believe your response that I have quoted addresses Luís's concerns about
> backward compatibility.

Thanks for your response.

As I explained I don't believe there ever was a :foreign-address
type. 

(defun foreign-allegro-type (type)
  (if (eq type :foreign-address)
     nil
....

explicitly made it irrelevant.

Why does Luís think there was a :foreign-address type? Since when has
any lisp had a type which is a :keyword? This is not a foreign-type but
a lisp type.

To reiterate, my patch solves two problems:

   use :unsigned-nat for pointers from C

   store it in an Lisp 'integer


Before CFFI use to try

   nil for pointers from C (meaning :int)

   store it in a Lisp :foreign-address -- a non-existent type -- (actually fortunately ignored because the first
   part was nil)


I'm not sure when :unsigned-nat was introduced . . . it is indeed very likely
that my patch will not work with old versions, in which case
:unsigned-long should be used.

According to franz.com:

:nat and :unsigned-nat: these were added in release 7.0.





More information about the cffi-devel mailing list