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?