... 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
Sorry, here is the patch.
Juanjo
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?
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
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.
-
Juan Jose Garcia-Ripoll -
Luís Oliveira