[cffi-devel] Lisp 5, Edgar 2 (and gaining)

[Ken Tilton]

cffi-devel-request at common-lisp.net wrote:

>Send cffi-devel mailing list submissions to
>	cffi-devel at common-lisp.net
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
>or, via email, send a message with subject or body 'help' to
>	cffi-devel-request at common-lisp.net
>
>You can reach the person managing the list at
>	cffi-devel-owner at common-lisp.net
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of cffi-devel digest..."
>
>
>Today's Topics:
>
>   1. CLisp exe vs FFI (Ken Tilton)
>   2. Re: Re: Clisp, cffi and defcfuns in a saved image
>      ( Edgar Gon?alves )
>   3. Re: CLisp finalizers ( Lu?s Oliveira )
>   4. New features ( Lu?s Oliveira )
>   5. Re: cffi-clisp.lisp multiple-value-bind usage of	variable
>      "error" conflicts with another package ( Lu?s Oliveira )
>   6. Re: New features (Stelian Ionescu)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Tue, 13 Feb 2007 13:53:41 -0500
>From: Ken Tilton <kentilton at gmail.com>
>Subject: [cffi-devel] CLisp exe vs FFI
>To: cffi-devel at common-lisp.net
>Message-ID: <45D20935.9010009 at gmail.com>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>I would consider as merely a first sanity-checking step simply using 
>native CLisp ffi to make one lousy call to SQL and get /that/ to work in 
>an exe. ie, reduce the number of variables in play.
>
>Then try it with CFFI, but not uffi-compat.
>
>Then with uffi-compat, but still writing my own (one?) bindings.
>
>Then worry about cl-sql bindings running thru a maze of FFIs.
>
>hth,kt
>
>
>------------------------------
>
>Message: 2
>Date: Tue, 13 Feb 2007 20:42:50 +0000
>From: " Edgar Gon?alves " <edgar.goncalves at gmail.com>
>Subject: Re: [cffi-devel] Re: Clisp, cffi and defcfuns in a saved
>	image
>To: " Lu?s Oliveira " <luismbo at gmail.com>
>Cc: cffi-devel at common-lisp.net
>Message-ID:
>	<6fd384780702131242i1f2b1a5ci2780bb7d9939fcab at mail.gmail.com>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>Ok, I've just realized that I've been mislocating the problem at
>hands. It seems that defcfun works just fine, and the issue I'm
>getting resides on the foreign pointers. I've made tests to cffi,
>cffi-uffi-compat, ffi (answering to Ken's "CLisp exe vs FFI"
>post), and all have worked for a simple function definition/call.
>So I delved again to clsql initial situation, and I've traced the
>error to a call to %new-environment-handle, that uses a null
>pointer as an argument to the ff call to SQLAllocHandle. I also
>noticed that the null pointer was indeed showing up at the error
>message, so I tried this simple test:
>
>,-----
>| (asdf:operate 'asdf:load-op 'cffi)
>| (asdf:operate 'asdf:load-op 'cffi-uffi-compat)
>| (defvar my-null-ptr (ffi:unsigned-foreign-address 0))
>| (format t "- Before loading image, null ptr is: ~A!~%" my-null-ptr)
>| (ext:saveinitmem "test.exe"
>| 		 :init-function #'(lambda ()
>| 				    (format t "- After loading image, my-null-ptr yelds: ~A.~%"
>my-null-ptr)
>| 				    (ext:quit))
>| 		 :NORC t
>| 		 :script t
>| 		 :executable t
>| 		 :quiet t)
>`-----
>
>
>The output I get when I run this code is (after the initial load messages),
>,-----
>| (...)
>| - Before loading image, null ptr is: #<FOREIGN-ADDRESS #x00000000>!
>| C:\dev\test>test
>| test
>| - After loading image, my-null-ptr yelds: #<INVALID FOREIGN-ADDRESS
>#x00000000>.
>`-----
>
>What makes a foreign address valid or invalid? Is there some way
>I can validate a simple null pointer? I could understand if a
>given non-null pointer in C would be hard to validate after
>restarting an image, but a null pointer is, and always will be,
>0x0, right?
>
>  
>
Well, clearly Clisp is taking care to keep private little notes about 
what you are up to, so I would not be too surprised that it finds a 
difference between zero and zero. ie, it has the thing boxed, so it aint 
just looking at zeros (as would a C compiler just looking at a long), it 
sees a pointer /wrapper/ which is cool interactive but not compiled, by 
which I mean:

I have no idea what I am talking about, but I suspect the problem is 
simply that the defvar form compiles with a foreign pointer allocated 
/at compile time/, and then t runtime that pointer is spotted by CLisp 
as not having been allocated during the run at hand. So...

So do not do that, ie, do not compile a dynamic foreign pointer 
allocation into your fasl, ie allocate my-ptr at runtime.

hth,kzo