>so you don't want to register these variables/functions in
No. That's solely a mechanism to make modules work.
>why give them a name then?
Because the name slot is there
and because the name is printed.
So this can help people manipulate those pesky pointers.
It's informative, no more.
It's especially useful with the foreign-function constructor (not shown).
One of my initial APIs was
;; already part of my DYNLOAD module
(defun foreign-address-function (name address ctype)
(check-type name (or null string))
i.e. one was obliged to supply a name or explicitly say NIL.
Another API was:
(defun ensure-foreign-function (ffunction ctype &optional name) #)
;- sort of cast for foreign-function objects.
The foreign variable and -function constructors must look very similar.
Probably people are more used to naming functions than variables or locations.
BTW, here's a deprecated entry out of my old FFI hacks toolbox
;this one does not preserve the foreign-address object, which is bad
'(defun fcast (ff c-type)
"Create a funcall'able FOREIGN-FUNCTION object at the given address"
;;TODO add setf foreign-pointer-base
(with-c-var (new-function 'c-pointer (foreign-address ff))
(cast new-function c-type)))
;(fcast #'c-self '(c-function (:return-type int)))
It's deprecated in favour of the foreign-address-function or foreign-function constructor which exhibits nicer properties.
It gives you an idea of what can be done with just plain exported FFI forms.
Get latest updates about Open Source Projects, Conferences and News.