[cffi-devel] Inline expansions for pointer operations
... provided in this patch. I have a couple of questions. One is whether NULL-POINTER has to cons a new pointer _every_time_. It would be more clever to create a variable and put the pointer there. The other one is whether MAKE-POINTER is used at all, given that we have pointer increment / decrement operations. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://tream.dreamhosters.com
Sorry, here is the patch. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://tream.dreamhosters.com
On Sun, Apr 25, 2010 at 6:43 PM, Juan Jose Garcia-Ripoll <juanjose.garciaripoll@googlemail.com> wrote:
... provided in this patch.
I have a few questions about this patch. (defun pointer-eq (ptr1 ptr2) "Return true if PTR1 and PTR2 point to the same address." - (= (ffi:pointer-address ptr1) (ffi:pointer-address ptr2))) + ;; In ECL two pointers are EQUAL if they point to the same address. + (equal ptr1 ptr2)) One advantage of the previous definition is that passing non-pointers to POINTER-EQ would (I assume) signal an error. What do you think? +(define-compiler-macro null-pointer () + '(si::allocate-foreign-data :void 0)) Any reason why a simpler (declaim (inline null-pointer)) wouldn't work just as well? -- Luís Oliveira http://r42.eu/~luis/
On Mon, Apr 26, 2010 at 1:11 AM, Luís Oliveira <luismbo@gmail.com> wrote:
On Sun, Apr 25, 2010 at 6:43 PM, Juan Jose Garcia-Ripoll <juanjose.garciaripoll@googlemail.com> wrote:
... provided in this patch.
I have a few questions about this patch.
(defun pointer-eq (ptr1 ptr2) "Return true if PTR1 and PTR2 point to the same address." - (= (ffi:pointer-address ptr1) (ffi:pointer-address ptr2))) + ;; In ECL two pointers are EQUAL if they point to the same address. + (equal ptr1 ptr2))
One advantage of the previous definition is that passing non-pointers to POINTER-EQ would (I assume) signal an error. What do you think?
If this is the intended behavior in all platforms then I will have to think about something else for the inline expansion as well -- is it ok if the error check is removed for low safety settings?
+(define-compiler-macro null-pointer () + '(si::allocate-foreign-data :void 0))
Any reason why a simpler (declaim (inline null-pointer)) wouldn't work just as well?
Such a proclamation would not get propagate anywhere -- ECL does not keep the definion of inline functions Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://tream.dreamhosters.com
On Mon, Apr 26, 2010 at 8:11 AM, Juan Jose Garcia-Ripoll <juanjose.garciaripoll@googlemail.com> wrote:
One advantage of the previous definition is that passing non-pointers to POINTER-EQ would (I assume) signal an error. What do you think?
If this is the intended behavior in all platforms then I will have to think about something else for the inline expansion as well -- is it ok if the error check is removed for low safety settings?
Yes, I would say so. This is sort of stuff that the CFFI-SYS spec should be careful about but isn't yet. I've just added a handful of tests for this sort of stuff. -- Luís Oliveira http://r42.eu/~luis/
participants (2)
-
Juan Jose Garcia-Ripoll -
Luís Oliveira