[cffi-devel] *parse-bare-structs-as-pointers*
Dow we really need *parse-bare-structs-as-pointers* ? It's only used in one place(parse-deprecated-struct-type) and IMO it's useless: we should parse bare structs as pointers unconditionally and issue a warning that it's deprecated and will be removed on 2013-05-01 -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ cffi-devel mailing list cffi-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
Re: [cffi-devel] Next release of CFFI with cffi-libffi
On Thu, 2012-04-19 at 14:46 +, Stas Boukarev wrote: Luís Oliveira luismbo at gmail.com writes: On Thu, Apr 19, 2012 at 2:50 PM, Stelian Ionescu sionescu at cddr.org wrote: (with-foreign-object (p '(:struct timespec) 2) (mem-aref p '(:struct timespec) 1)) In order not to break existing code [...] Existing code will not have this (:struct foo) syntax because it was introduced by the libffi merge. (mem-aref p 'timespec 1) should exhibit backwards-compatible behaviour. Turns out, the problem is not with mem-aref, but with the mem-aref compile- macro. It binds *parse-bare-structs-as-pointers* to T, whereas mem-aref function doesn't, this affects the result of foreign-type-size. Actually it's mem-aref that should bind *parse-bare-structs-as-pointers* to T, so I pushed the fix -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ cffi-devel mailing list cffi-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
Re: [cffi-devel] Next release of CFFI with cffi-libffi
Stelian Ionescu sione...@cddr.org writes: On Thu, 2012-04-19 at 14:46 +, Stas Boukarev wrote: Luís Oliveira luismbo at gmail.com writes: On Thu, Apr 19, 2012 at 2:50 PM, Stelian Ionescu sionescu at cddr.org wrote: (with-foreign-object (p '(:struct timespec) 2) (mem-aref p '(:struct timespec) 1)) In order not to break existing code [...] Existing code will not have this (:struct foo) syntax because it was introduced by the libffi merge. (mem-aref p 'timespec 1) should exhibit backwards-compatible behaviour. Turns out, the problem is not with mem-aref, but with the mem-aref compile- macro. It binds *parse-bare-structs-as-pointers* to T, whereas mem-aref function doesn't, this affects the result of foreign-type-size. Actually it's mem-aref that should bind *parse-bare-structs-as-pointers* to T, so I pushed the fix This breaks it. (cffi:defcstruct foo (a :short) (b :short)) ;; After binding *parse-bare-structs-as-pointers* to T in the mem-aref function: (cffi:with-foreign-object (var 'foo 20) (let ((type 'foo)) (cffi:mem-aref var type))) ;; new cffi = #.(SB-SYS:INT-SAP #X) ;; old cffi and new with a constant type return an expected address ;; Previous problems I originally described: (cffi:with-foreign-object (var 'foo 2) (- (cffi-sys:pointer-address (cffi:mem-aref var 'foo 1)) (cffi-sys:pointer-address (cffi:mem-aref var 'foo 0 ;; old cffi = 4 ;; new cffi = 8 ;; With mem-aptr works as expected: (cffi:with-foreign-object (var 'foo 2) (- (cffi-sys:pointer-address (cffi:mem-aptr var 'foo 1)) (cffi-sys:pointer-address (cffi:mem-aptr var 'foo 0 ;; new cffi = 4 -- With best regards, Stas. ___ cffi-devel mailing list cffi-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
Re: [cffi-devel] Next release of CFFI with cffi-libffi
Stas Boukarev stass...@gmail.com writes: Stelian Ionescu sione...@cddr.org writes: On Thu, 2012-04-19 at 14:46 +, Stas Boukarev wrote: Luís Oliveira luismbo at gmail.com writes: On Thu, Apr 19, 2012 at 2:50 PM, Stelian Ionescu sionescu at cddr.org wrote: (with-foreign-object (p '(:struct timespec) 2) (mem-aref p '(:struct timespec) 1)) In order not to break existing code [...] Existing code will not have this (:struct foo) syntax because it was introduced by the libffi merge. (mem-aref p 'timespec 1) should exhibit backwards-compatible behaviour. Turns out, the problem is not with mem-aref, but with the mem-aref compile- macro. It binds *parse-bare-structs-as-pointers* to T, whereas mem-aref function doesn't, this affects the result of foreign-type-size. Actually it's mem-aref that should bind *parse-bare-structs-as-pointers* to T, so I pushed the fix This breaks it. And the same problem with *parse-bare-structs-as-pointers* being different is also present in the setf macro for mem-aref. -- With best regards, Stas. ___ cffi-devel mailing list cffi-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
Re: [cffi-devel] Next release of CFFI with cffi-libffi
On Tue, 2012-05-01 at 00:00 +0400, Stas Boukarev wrote: Stas Boukarev stass...@gmail.com writes: Stelian Ionescu sione...@cddr.org writes: On Thu, 2012-04-19 at 14:46 +, Stas Boukarev wrote: Luís Oliveira luismbo at gmail.com writes: On Thu, Apr 19, 2012 at 2:50 PM, Stelian Ionescu sionescu at cddr.org wrote: (with-foreign-object (p '(:struct timespec) 2) (mem-aref p '(:struct timespec) 1)) In order not to break existing code [...] Existing code will not have this (:struct foo) syntax because it was introduced by the libffi merge. (mem-aref p 'timespec 1) should exhibit backwards-compatible behaviour. Turns out, the problem is not with mem-aref, but with the mem-aref compile- macro. It binds *parse-bare-structs-as-pointers* to T, whereas mem-aref function doesn't, this affects the result of foreign-type-size. Actually it's mem-aref that should bind *parse-bare-structs-as-pointers* to T, so I pushed the fix This breaks it. And the same problem with *parse-bare-structs-as-pointers* being different is also present in the setf macro for mem-aref. Ok, I reverted that patch because it's now obvious that I misunderstood the problem, the bug seems to be in the compiler-macro: CFFI (cffi:defcstruct foo (a :uint8)) = (:STRUCT FOO) CFFI (cffi:with-foreign-object (var 'foo 2) (declare (inline mem-aref)) (- (cffi-sys:pointer-address (cffi:mem-aref var 'foo 1)) (cffi-sys:pointer-address (cffi:mem-aref var 'foo 0 = 8 CFFI (cffi:with-foreign-object (var 'foo 2) (declare (notinline mem-aref)) (- (cffi-sys:pointer-address (cffi:mem-aref var 'foo 1)) (cffi-sys:pointer-address (cffi:mem-aref var 'foo 0 = 1 -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part ___ cffi-devel mailing list cffi-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
Re: [cffi-devel] *parse-bare-structs-as-pointers*
On Mon, Apr 30, 2012 at 7:30 PM, Stelian Ionescu sione...@cddr.org wrote: Dow we really need *parse-bare-structs-as-pointers* ? It's only used in one place(parse-deprecated-struct-type) and IMO it's useless: we should parse bare structs as pointers unconditionally and issue a warning that it's deprecated and will be removed on 2013-05-01 This is a good question. I was wondering about this myself, since I couldn't quite remember why I had introduced it. Turns out it is necessary. The problem is that struct types used to behave as pointers in some situations and as aggregate types in others. Blindly converting every RANDOM-STRUCT-TYPE to (:POINTER (:STRUCT RANDOM-STRUCT-TYPE)) would lead to incorrect results in various places: FOREIGN-TYPE-SIZE, FOREIGN-SLOT-VALUE, DEFCSTRUCT, etc. We might be able to simplify the code a little bit if we flipped its default value to be true, though. In any case, we already issue a deprecation warning, and we should definitely remove this backwards compatibility mess at some point. Not sure about the time frame, though. After the next CFFI release, we'll wait and see how fast CFFI-using libraries adapt. -- Luís Oliveira http://r42.eu/~luis/ ___ cffi-devel mailing list cffi-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
Re: [cffi-devel] Next release of CFFI with cffi-libffi
On Mon, Apr 30, 2012 at 11:02 PM, Max Mikhanosha m...@openchat.com wrote: This fixes it for me (defmethod foreign-type-size ((type symbol)) (let ((*parse-bare-structs-as-pointers* nil)) (foreign-type-size (parse-type type Thanks everyone for digging into this. While this fix does indeed fix the problem (nice catch!), using this special variable *PARSE-BARE-STRUCTS-AS-POINTERS* clearly turned out to be an overcomplicated and brittle approach. I've pushed a rewrite that should be much more robust. The key code path is is this in define-compiler-macro mem-aref (mem-ref ,ptr ,type (* ,index ,(foreign-type-size (eval type This highlights an important issue. We were not testing the non-compiler-macro code paths on SBCL. I've submitted a patch for RT that should help with that. As Stelian mentioned on IRC, we should perhaps control the deactivation of compiler macros explicitly rather than rely on EVAL not to use them. Curiously, forcing SBCL to use its interpreter revealed a possible bug: https://bugs.launchpad.net/sbcl/+bug/992362. -- Luís Oliveira http://r42.eu/~luis/ ___ cffi-devel mailing list cffi-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
